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“Head First Software Development is a whimsical but very thoughtfully designed series of information 
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— Adam Z. Szymanski, Software Project Manager，Naval Research Laboratory 
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development team from requirements through delivery.” 
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or even for those who have been Java programmers for a while but have been scared off by the massive 
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— Kyle Brown, Distinguished Engineer, IBM 

“Finally a book on OOA&D that recognizes that the UML is just a notation and that what matters when 
developing software is taking the time to think the issues through.” 

— Pete McBreen ， Author, Software Craftsmanship 

“The book does a good job of capturing that entertaining, visually oriented, 'Head First’ writing style. 
But hidden behind the funny pictures and crazy fonts is a serious, intelligent, extremely well-crafted 
presentation of OO Analysis and Design. This book has a strong opinion of how to design programs, 
and communicates it effectively. I love the way it uses running examples to lead the reader through the 
various stages of the design process. As I read the book, I felt like I was looking over the shoulder of an 
expert designer who was explaining to me what issues were important at each step, and why.” 

— Edward Sciore, Associate Professor，Computer Science Department 
Boston College 


“This is a well-designed book that delivers what it promises to its readers: how to analyze, design, and 
write serious object-oriented software. Its contents flow effortlessly from using use cases for capturing 
requirements to analysis, design, implementation, testing, and iteration. Every step in the development 
of object-oriented software is presented in light of sound software engineering principles. The examples 
are clear and illustrative. This is a solid and refreshing book on object-oriented software development.” 


— Dung Zung Nguyen，Lecturer 
Rice University 



Praise for Head First Design Patterns 


“I received the book yesterday and started to read it on the way home... and I couldn’t stop. I took it to 
the gym and I expect people saw me smiling a lot while I was exercising and reading. This is tres ‘cool’. 
It is fun but they cover a lot of ground and they are right to the point. I’m really impressed.” 
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and co-author of Design Patterns 
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great software development 

Pleasing your customer 

If the customer’s unhappy, everyone's unhappy! 

Every great piece of software starts with a customer’s big idea. It’s your job as a 
professional software developer to bring those ideas to life. But taking a vague 
idea and turning it into working code — code that satisfies your customer — isn’t 
so easy. In this chapter you’ll learn how to avoid being a software development 
casualty by delivering software that is needed, on-time, and on-budget. Grab 
your laptop and let's set out on the road to shipping great software. 
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gathering rec^mrenieirts 

Knowing what the customer wants 

You can’t always get what you want... but the customer better! 

Great software development delivers what the customer wants. This chapter is all about 
talking to the customer to figure out what their requirements are for your software. 

You’ll learn how user stories, brainstorming, and the estimation game help you get 
inside your customer’s head. That way, by the time you finish your project, you’ll be 
confident you’ve built what your customer wants... and not just a poor imitation. 
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project planning 

■arming for success 


very great piece of software starts with a great plan. 

In this chapter you’re going to learn how to create that plan. You’re going to learn how to 
rk with the customer to prioritize their requirements. You’ll define iterations that you 


and your team can then work towards. Finally you’ll create an achievable development 
plan that you and your team can confidently execute and monitor. By the time you’re 
done, you’ll know exactly how to get from requirements to milestone 1.0. 


Customers want their software NOW! 70 

Prioritize with the customer 73 


We know what’s in Milestone 1.0 (well, maybe) 74 

If the features don’t fit, re-prioritize 75 

More people sometimes means diminishing returns 77 
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Iterations should be short and sweet 85 


Here's what a programmer SAYS 



Comparing your plan to reality 

Velocity accounts for overhead in your estimates 

Programmers think in UTOPIAN days... 

Developers think in REAL-WORLD days... 

When is your iteration too long? 

Deal with velocity BEFORE you break into iterations 

Time to make an evaluation 

Managing customers 
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How to min your team’s lives 


87 

89 

90 

91 

92 

93 

97 

98 
100 
103 


...but here's what he's really THINKING 


I’ll grab a Monster on the way home, program 'til 3 
AM, take a Halo break, then work through the morning. 
Sleep a few hours, get the guys over to hack with me, 
and finish at midnight. As long as nothing goes wrong... 
and Mom doesn’t need me to pick up dinner. 
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4 Getting to the real work 

It’S time to go to work. User stories captured what you need to develop, but now 
it’s time to knuckle down and dish out the work that needs to be done so that you can 
bring those user stories to life. In this chapter you’ll learn how to break your user stories 
into tasks, and how your task estimates help you track your project from inception to 
completion. You’ll learn how to update your board, moving tasks from in-progress, to 
complete, to finally completing an entire user story. Along the way, you’ll handle and 
prioritize the inevitable unexpected work your customer will add to your plate. 


Your first standup meeting... 
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good-enough design 

Getting it done with great design 

Good design helps you deliver. In the last chapter things were looking pretty 
dire. A bad design was making life hard for everyone and, to make matters worse, an 
unplanned task cropped up. In this chapter you’ll see how to refactor your design so that 
you and your team can be more productive. You’ll apply principles of good design, 
while at the same time being wary of striving for the promise of the ‘perfect design’. 
Finally you’ll handle unplanned tasks in exactly the same way you handle all the other 
work on your project using the big project board on your wall. 



iSwoon is in serious trouble... 

This design breaks the single responsibility principle 
Spotting multiple responsibilies in your design 
Going from multiple responsibilies to a single responsibility 
Your design should obey the SRP, but also be DRY... 

The post-refactoring standup meeting... 

Unplanned tasks are still just tasks 
Part of your task is the demo itself 
When everything’s complete, the iteration’s done 
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Version contrd 

Defensive development 

When it comes to writing great software, Safety First! 

Writing great software isn’t easy... especially when you’ve got to make sure your code 
works, and make sure it keeps working. All it takes is one typo, one bad decision 
from a co-worker, one crashed hard drive, and suddenly all your work goes down the 
drain. But with version control, you can make sure your code is always safe in a 
code repository, you can undo mistakes, and you can make bug fixes —— to new and 
old versions of your software. 
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PeatPox Pro 1.x 



You’ve got a new contract —— BeatBox Pro 178 

And now the GUI work... 182 

Demo the new BeatBox for the customer 185 
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bu!lc[!ng your code 

Insert tab a into slot b … 

It pays to follow the instructions... 

...especially when you write them yourself. 

It’s not enough to use configuration management to ensure your code stays safe. You’ve 
also got to worry about compiling your code and packaging it into a deployable unit. On 
top of all that, which class should be the main class of your application? How should that 
class be run? In this chapter, you’ll learn how a build tool allows you to write your own 
instructions for dealing with your source code. 


Developers aren’t mind readers 220 

Building your project in one step 221 

Ant: a build tool for Java projects 222 
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testing and continuous !ntegrciti9n 

Things fall apart 

Sometimes even the best developer breaks the build. 

Everyone’s done it at least once. You’re sure your code compiles, you’ve tested it over 
and over again on your machine and committed it into the repository. But somewhere 
between your machine and that black box they call a server someone must have changed 
your code. The unlucky soul who does the next checkout is about to have a bad morning 
sorting out what used to be working code. In this chapter we’ll talk about how to put 
together a safety net to keep the build in working order and you productive. 




Black-Lox testing 


Things will ALWAYS go wrong... 

There are three ways to look at your system... 
Black-box testing focuses on INPUT and OUTPUT 
Grey-box testing gets you CLOSER to the code 
White-box testing uses inside knowledge 
Testing EVERYTHING with one step 
Automate your tests with a testing framework 
Use your framework to run your tests 
At the wheel of Cl with CruiseGontrol 
Testing guarantees things will work... right? 

Testing all your code means testing EVERY BRANCH 
Use a coverage report to see what’s covered 
Getting good coverage isn’t always easy... 

What CM does... 

Tools for your Software Development Toolbox 
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test-drlVen c[eVelopmeitt 

Holding your code accountable 

Sometimes it’s all about setting expectations. Good code needs to 

work, everyone knows that. But how do you know your code works? Even with unit 
testing, there are still parts of most code that goes untested. But what if testing was a 
fundamental part of software development? What if you did everything with testing in 
mind? In this chapter, you’ll take what you know about version control, Cl, and automated 
testing and tie it all together into an environment where you can feel confident about 
fixing bugs, refactoring, and even reimplementing parts of your system. 


Test FIRST, not last 276 

So we’re going to test FIRST... 277 

Welcome to test-driven development 277 
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...fails miserably. 279 
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Red, green, refactor... 281 
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When your tests pass, move on! 

Simplicity means avoiding dependencies 
Always write testable code 

When things get hard to test, examine your design 
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ending an iteratiQii 

It’s all conning together... 

You’re almost finished! The team’s been working hard and things are 
wrapping up. Your tasks and user stories are complete, but what’s the best way 
to spend that extra day you ended up with? Where does user testing fit in? 

Can you squeeze in one more round of refactoring and redesign? And there 


sure are a lot of lingering bugs... when do those get fixed? It’s all part of the 
end of an iteration... so let’s get started on getting finished. 



Your iteration is just about complete... 

...but there’s lots left you could do 
System testing MUST be done... 

...but WHO does system testing? 

System testing depends on a complete system to test 
Good system testing requires TWO iteration cycles 
More iterations means more problems 
Top 10 Traits of Effective System Testing 
The life (and death) of a bug 
So you found a bug.... 

Anatomy of a bug report 

But there’s still plenty left you GOULD do... 

Time for the iteration review 
Some iteration review questions 

A GENERAL priority list for getting EXTRA things done... 
Tools for your Software Development Toolbox 
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If it ain’t broke...you still better fix it 

Think things are going well? 

Hold on, that just might change... 

Your iteration went great, and you’re delivering working software on-time. 
Time for the next iteration? No problem, right? Unfortunately, not right at 
all. Software development is all about change, and moving to your next 
iteration is no exception. In this chapter you’ll learn how to prepare for the 
next iteration. You’ve got to rebuild your board and adjust your stories 
and expecations based on what the customer wants NOW, not a month ago. 


What is working software? 350 

You need to plan for the next iteration 352 

Velocity accounts for... the REAL WORLD 359 

And it’s STILL about the customer 360 

Someone else’s software is STILL just software 362 

Customer approval? Check! 365 
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bugs 

Squashing bugs like a pro 

Your code, your responsibility...your bug, your reputation! 

When things get tough, it’s up to you to bring them back from the brink. Bugs, whether 
they’re in your code or just in code that your software uses, are a fact of life in software 
development. And, like everything else, the way you handle bugs should fit into the rest 
of your process. You’ll need to prepare your board, keep your customer in the loop, 
confidently estimate the work it will take to fix your bugs, and apply refactoring and 
prefactoring to fix and avoid bugs in the future. 


Previously on Iteration 2 386 

First, you’ve got to talk to the customer 386 

Priority one: get things buildable 392 

We could fix code... 394 

...but we need to fix functionality 395 

Figure out what functionality works 396 

NOW you know what’s not working 399 

What would you do? 399 

Spike test to estimate 400 

What do the spike test results tell you? 402 

Your team’s gut feel matters 404 

Give your customer the bug fix estimate 406 

Things are looking good... 410 

...and you finish the iteration successfully! 411 

AND the customer is happy 412 
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the real world 

Having a process in life 

You’ve learned a lot about Software Development. But before you 

go pinning burn down graphs in everyone’s office, there’s just a little more you need to 
know about dealing with each project... on its own terms. There are a lot of similarities 
and best practices you should carry from project to project, but there are unique things 
everywhere you go, and you need to be ready for them. It’s time to look at how to apply 
what you’ve learned to your particular project, and where to go next for more learning 



Pinning down a software development process 
A good process delivers good software 
Formal attire required... 

Some additional resources... 

More knowledge 二 = better process 

Tools for your Software Development Toolbox 
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appendix 1 ： leftovers 

The top 5 things (we didn’t cover) 

Ever feel like something’s missing? We know what you mean... 

Just when you thought you were done... there’s more. We couldn’t leave you without a few 
extra things, things we just couldn’t fit into the rest of the book. At least, not if you want to 


be able to carry this book around without a metallic case and castor wheels on the bottom. 


So take a peek and see what you (still) might be missing out on. 


#1. UML class Diagrams 
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appendix 2 ： techniques and principles 

Tools for the experienced software developer 



U Ever wished all those great tools and techniques were 
in one place? This is a roundup of all the software development 
techniques and principles we’ve covered. Take a look over them all, and 
see if you can remember what each one means. You might even want to 
cut these pages out and tape them to the bottom of your big board, for 
everyone to see in your daily standup meetings. 

Development Techniques 444 

Development Principles 446 
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how to use this book 


Who is this book for? 


If you can answer “yes” to all of these: 


① 

② 


Do you have access to a computer and some 
background in programming? 



Do you want to learn techniques for building and 
delivering great software? Do you want to understand the 

principles behind iterations and test-driven development? 


M use Java ih the book, but 
you 匕 sc^uih-t ay\d pvctchd 

S c#. Wo amouh-t of 

will make you tUk 
'■t s Pcirl, -though. 


③ 


Do you prefer stimulating dinner party conversation to 
dry, dull, academic lectures? 


this book is for you. 


Who should probably back away from this book? 

If you can answer “yes” to any of these: 


① 


Are you completely new to Java? 

(You don’t need to be advanced, and if you know C++ or 
C# you’ll understand the code examples just fine.) 


② 


Are you a kick-butt development manager looking for a 

reference book? 


③ 


Are you afraid to try something different? Would you 
rather have a root canal than mix stripes with plaid? 

Do you believe that a technical book can’t be serious if 
iterations are anthropomorphized? 


this book is not for you. 



^ -this book is 

^ 4 a t>rtd\i U\rA3 
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Wc know what youVe thinking 


cc 


u 


How can this be a serious software development book? 
What’s with all the graphics?” 

Gan I actually learn it this way?” 


5 ? 


Wc know what your brain is thinking 

Your brain craves novelty. It’s always searching, scanning, waiting for something 
unusual. It was built that way, and it helps you stay alive. 

So what does your brain do with all the routine, ordinary, normal things you 
encounter? Everything it can to stop them from interfering with the brain’s 
real job — recording things that matter. It doesn’t bother saving the boring 
things; they never make it past the “this is obviously not important” filter. 

How does your brain know what’s important? Suppose you’re out for a 
day hike and a tiger jumps in front of you, what happens inside your head 
and body? 

Neurons fire. Emotions crank up. Chemicals surge. 

And that’s how your brain knows... 

This must be important! Don’t forget it! 

But imagine you’re at home, or in a library. It’s a safe, warm, tiger-free zone. 
You’re studying. Getting ready for an exam. Or trying to learn some tough 
technical topic your boss thinks will take a week, ten days at the most. 

Just one problem. Your brain’s trying to do you a big favor. It’s trying 
to make sure that this obviously non-important content doesn’t clutter 
up scarce resources. Resources that are better spent storing the really 
big things. Like tigers. Like the danger of fire. Like the guy with the 
handle “BigDaddy” on MySpace probably isn’t someone to meet 
with after 6 PM. 

And there’s no simple way to tell your brain, “Hey brain, thank you 
very much, but no matter how dull this book is, and how little I’m 
registering on the emotional Richter scale right now, I really do want 
you to keep this stuff around.” 
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Metacognition: thinking about thinking 

If you really want to learn, and you want to learn more quickly and more 
deeply, pay attention to how you pay attention. Think about how you think. 
Learn how you learn. 

Most of us did not take courses on metacognition or learning theory when we 
were growing up. We were expected to learn, but rarely taught to learn. 


I wonder how 
I can trick my brain 
into remembering 
this stuff... 



But we assume that if you’re holding this book, you really want to learn how 
to really develop great software. And you probably don’t want to spend a lot 
of time. If you want to use what you read in this book, you need to remember 
what you read. And for that, you’ve got to understand it. To get the most from 
this book, or any book or learning experience, take responsibility for your brain. 
Your brain on this content. 


The trick is to get your brain to see the new material you’re learning as 
Really Important. Crucial to your well-being. As important as a tiger. 
Otherwise, you’re in for a constant battle, with your brain doing its best 
keep the new content from sticking. 


to 


So just how DO you get your brain to treat software 
development like it was a hungry tiger? 


There’s the slow, tedious way, or the faster, more effective way. The 
slow way is about sheer repetition. You obviously know that you are able to learn 
and remember even the dullest of topics if you keep pounding the same thing into your 
brain. With enough repetition, your brain says, “This doesn’t feel important to him, but he 
keeps looking at the same thing over and over and over, so I suppose it must be.” 


The faster way is to do anything that increases brain activity, especially different 
types of brain activity. The things on the previous page are a big part of the solution, 
and they’re all things that have been proven to help your brain work in your favor. For 
example, studies show that putting words within the pictures they describe (as opposed to 
somewhere else in the page, like a caption or in the body text) causes your brain to try to 
makes sense of how the words and picture relate, and this causes more neurons to fire. 
More neurons firing = more chances for your brain to get that this is something worth 
paying attention to, and possibly recording. 


A conversational style helps because people tend to pay more attention when they 
perceive that they’re in a conversation, since they’re expected to follow along and hold up 
their end. The amazing thing is, your brain doesn’t necessarily care that the “conversation” 
is between you and a book! On the other hand, if the writing style is formal and dry, your 
brain perceives it the same way you experience being lectured to while sitting in a roomful 
of passive attendees. No need to stay awake. 


But pictures and conversational style are just the beginning... 
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Here's what WE did: 

We used pictures, because your brain is tuned for visuals, not text. As 
far as your brain’s concerned, a picture really is worth a thousand words. 
And when text and pictures work together, we embedded the text in the 
pictures because your brain works more effectively when the text is within 
the thing the text refers to, as opposed to in a caption or buried in the text 
somewhere. 



We used redundancy, saying the same thing in different ways and with different media types, 
and multiple senses, to increase the chance that the content gets coded into more than one area 
of your brain. 

We used concepts and pictures in unexpected ways because your brain is tuned for novelty, 
and we used pictures and ideas with at least some emotional content, because your brain 
is tuned to pay attention to the biochemistry of emotions. That which causes you to feel 
something is more likely to be remembered, even if that feeling is nothing more than a little 

humor, surprise, or interest. 

We used a personalized, conversational style, because your brain is tuned to pay more 
attention when it believes you’re in a conversation than if it thinks you’re passively listening 
to a presentation. Your brain does this even when you’re reading. 



We included more than 80 activities, because your brain is tuned to learn and remember 
more when you do things than when you read about things. And we made the exercises 
challenging-yet-do-able, because that’s what most people prefer. 

We used multiple learning styles, because might prefer step-by-step procedures, while 
someone else wants to understand the big picture first, and someone else just wants to see 
an example. But regardless of your own learning preference, everyone benefits from seeing the 
same content represented in multiple ways. 

We include content for both sides of your brain, because the more of your brain you 
engage, the more likely you are to learn and remember, and the longer you can stay 
focused. Since working one side of the brain often means giving the other side a chance to 
rest, you can be more productive at learning for a longer period of time. 



And we included stories and exercises that present more than one point of view ， 
because your brain is tuned to learn more deeply when it’s forced to make evaluations and 
judgments. 

We included challenges, with exercises, and by asking questions that don’t always have 
a straight answer, because your brain is tuned to learn and remember when it has to work at 
something. Think about it — you can’t get your body in shape just by watching people at the 
gym. But we did our best to make sure that when you’re working hard, it’s on the right things. 
Thsityou y re not spending one extra dendrite processing a hard-to-understand example, 
or parsing difficult, jargon-laden, or overly terse text. 

We people. In stories, examples, pictures, etc. ， because, well, because j ⑽ Ye a person. 
And your brain pays more attention to people than it does to things. 
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Here's what YOU caw do to bend 
your brain into submission 

So, we did our part. The rest is up to you. These tips are a 
starting point; listen to your brain and figure out what works 
for you and what doesn’t. Try new things. 

Cut -this out «>hd sti 乙 k 
° h y ° 讲 


Slow down. The more you understand, 
the less you have to memorize. 

Don’t just read. Stop and think. When the 
book asks you a question, don’t just skip to the 
answer. Imagine that someone really is asking 
the question. The more deeply you force your 
brain to think, the better chance you have of 
learning and remembering. 

( 2 ) Do the exercises. Write your own notes. 

We put them in, but if we did them for you, 
that would be like having someone else do 
your workouts for you. And don’t just look at 
the exercises. Use a pencil. There’s plenty of 
evidence that physical activity while learning 
can increase the learning. 

^3^ Read the “There are No Dumb Questions” 

That means all of them. They’re not optional 
sidebars — they } re part of the core content! 

Don’t skip them. 

^4^ Make this the last thing you read before 
bed. Or at least the last challenging thing. 

Part of the learning (especially the transfer to 
long-term memory) happens after yow put the 
book down. Your brain needs time on its own, to 
do more processing. If you put in something new 
during that processing time, some of what you 
just learned will be lost. 


Talk about it. Out loud. 

Speaking activates a different part of the brain. 

If you’re trying to understand something, or 
increase your chance of remembering it later, say 
it out loud. Better still, try to explain it out loud 
to someone else. You’ll learn more quickly, and 
you might uncover ideas you hadn’t known were 
there when you were reading about it. 

^7^ Listen to your brain. 

Pay attention to whether your brain is getting 
overloaded. If you find yourself starting to skim 
the surface or forget what you just read, it’s time 
for a break. Once you go past a certain point, you 
won’t learn faster by trying to shove more in, and 
you might even hurt the process. 

Feel something. 

Your brain needs to know that this matters. Get 
involved with the stories. Make up your own 
captions for the photos. Groaning over a bad joke 
is still better than feeling nothing at all. 

^9^ Write a lot of software! 

There’s only one way to learn to develop software: 
you have to actually develop software. And 

that’s what you’re going to do throughout this 
book. We’re going to give you lots of requirements 
to capture, techniques to evaluate, and code to 
test and improve: every chapter has exercises that 
pose a problem for you to solve. Don’t just skip 
over them — a lot of the learning happens when 
you solve the exercises. We included a solution to 
each exercise — don’t be afraid to peek at the 
solution if you get stuck! (It’s easy to get snagged 
on something small.) But try to solve the problem 
before you look at the solution. 


( 5 ^ Drink water. Lots of it. 

Your brain works best in a nice bath of fluid. 
Dehydration (which can happen before you ever 
feel thirsty) decreases cognitive function. 
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Read Me 

This is a learning experience, not a reference book. We deliberately stripped out everything 
that might get in the way of learning whatever it is we’re working on at that point in the 
book. And the first time through, you need to begin at the beginning, because the book 
makes assumptions about what you’ve already seen and learned. 


We assume you are familiar with object-oriented programming. 

It would take an entire book to teach you object-oriented programming (like, say, Head 
First OOA&D). We chose to focus this book on software development principles rather 
than design or language basics. We picked Java for our examples because it’s fairly 
common, and pretty self-documenting; but everything we talk about should apply whether 
you’re using Java, G#, C++, or Visual Basic (or Ruby, or...) However, if you’ve never 
programmed using an object-oriented language, you may have some trouble following 
some of the code. In that case we’d strongly recommend you get familiar with one of those 
languages before attacking some of the later chapters in the book. 


We don’t cover every software development process out there. 

There are tomes of information about different ways to write software. We don’t try to 
cover every possible approach to developing code. Instead, we focus on techniques that 
we know work and fit well together to produce great software. Chapter 12 specifically talks 
about ways to tweak your process to account for unique things on your project. 


The activities are NOT optional. 

The exercises and activities are not add-ons; they’re part of the core content of the book. 
Some of them are to help with memory, some are for understanding, and some will help 
you apply what you’ve learned. Some exercises are there just to make you think about how 
you would solve the problem. Don } t skip the exercises. The crossword puzzles are the 
only thing you don’t have to do, but they’re good for giving your brain a chance to think 
about the words and terms you’ve been learning in a different context. 
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The redundancy is intentional and important. 

One distinct difference in a Head First book is that we want you to really get it. And we 
want you to finish the book remembering what you’ve learned. Most reference books 
don’t have retention and recall as a goal, but this book is about learning, so you’ll see some 
of the same concepts come up more than once. 


The examples are as lean as possible. 

Our readers tell us that it’s frustrating to wade through 200 lines of an example looking 
for the two lines they need to understand. Most examples in this book are shown within 
the smallest possible context, so that the part you’re trying to learn is clear and simple. 
Don’t expect all of the examples to be robust, or even complete — they are written 
specifically for learning, and aren’t always fully functional. 

We’ve placed the full code for the projects on the Web so you can copy and paste them 
into your text editor. You’ll find them at: 

http:/ / www.headfirstlabs.com/books/hfsd/ 

The Brain Power exercises don’t have answers. 

For some of them, there is no right answer, and for others, part of the learning 
experience of the Brain Power activities is for you to decide if and when your answers 
are right. In some of the Brain Power exercises, you will find hints to point you in the 
right direction. 
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The technical review team 
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/WdClellah W 
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Technical Reviewers: 


This book wouldn’t be anything like it is without our technical reviewers. They 
called us out when they disagreed with something, gave us “hurrah’’s when 
something went right, and sent back lots of great commentary on things that 
worked and didn’t work for them in the real world. Each of them brought a 
different perspective to the book, and we really appreciate that. For instance, Dan 
Francis and McClellan Francis made sure this book didn’t turn into Software 
Development for Java. 


We’d particularly like to call out Faisal Jawad for his thorough and supportive 
feedback (he started the “hurrahs”). Burk Hufnagel provided great suggestions 
on other approaches he’d used on projects and made one author’s late night of 
updates a lot more fun with his suggestion to include, “Bad dev team. No biscuit.” 

Finally, we’d like to thank Lisa Kellner and Kristin Stromberg for their great 
work on readability and pacing. This book wouldn’t be what it is without all of 
your input. 
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Safari© Pooks Online 


Safari .》 

Books Online 


When you see a Safari® icon on the cover of your favorite 
technology book that means the book is available online 
through the O’Reilly Network Safari Bookshelf. 


Safari offers a solution that’s better than e-books. It’s a virtual library that lets you 
easily search thousands of top tech books, cut and paste code samples, download 
chapters, and find quick answers when you need the most accurate, current 
information. Try it for free at http : // safari . oreilly. com. 
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Pleasing your customer ♦ 



If your customer’s unhappy, everyone's unhappy! 

Every great piece of software starts with a customer’s big idea. It’s your job as 
a professional software developer to bring that idea to life. But taking a vague 
idea and turning it into working code —— code that satisfies your customer — isn’t 
so easy. In this chapter you’ll learn how to avoid being a software development 
casualty by delivering software that is needed, on time, and on budget. Grab 
your laptop, and let’s set out on the road to shipping great software. 


this is a new chapter 



Tom's Trails 


Tom's Trails is going online 

Trekkin’ Tom has been providing world-famous trail guides and 
equipment from his shack in the Rockies for years. Now ，he wants 
to ramp up his sales using a bit of the latest technology. 



Tom -to iakc his 
business io the Ihtcv-hct 


0 


o 


No one does trail guides 
like mine...But the big TrailMix 
Conference is coming, and I want 
to show everybody what the next 
evolution in hiking looks like, Web- 
style. 


o 



Tow’s vision 
of WsTraiU 

Or\\y\t 
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Most projects have major concerns 

Talk to most customers and, besides their big idea, 
they’ve probably got two basic concerns: 


How much will it cost? 


No surprise here. Most customers want to figure out 
how much cash they’ll have to spend. In this case, 
though, Tom has a pile of money, so that’s not much 
of a concern for him. 



Usually, c,as\\ is a limi-btioh. (h this 

i ast, To¥n，s 9°^ io spame, ahd 

士，他 he spchds wilUua iKrto 

bigger pile. 



How long will it take? 


The other big constraint is time. Almost no customer 
ever says, “Take as long as you want!” And lots of the 
time, you have a specific event or date the customer 
wants their software ready for. 


In Tom’s case, he wants his website available in three 
months’ time, ready for the big TrailMix Conference 


coming up. 





This is youm payday, W.if 

y° u -finished Oh 
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the Big Bang approach 


The Pig Pang approach to development 

With only a month to get finished, there’s no time to waste. 

The lead developer Tom hired gets right to work. 



Here are my rough ideas 
for you to get started on. 


a,d 


Some HTML, CSS, a little 
backend Java...this will be 


a piece of cake. 


pasA C oAc 
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Flash forward: two weeks later 


Tom’s lead developer has pulled out all the stops to build 
Tom’s Trails Online, putting all her finest coding skills into 
play and producing what she thinks Tom wants her to build. 







Whew! That was hard work! 
I've been coding like crazy, 
working stupid hours, but at 
least now ifs time to collect 
that paycheck... 


Deliver! 


more 


code 


Whai 

tawc va\> 如从 … 


^ a lot ad 七 “ 

綱 4 somctW.^ av^d 

f ) coj^ 加 es 。乩 oUk 

all a*t … ，， 

X ...also as Pavk," as 

i\,t dusto^cv- sees you at the 

• IS delweved a 七栋 c Chd. 
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the Big Bang ends with a big mess 


Pig ba"g development usually ends 
up m a _ MESS 

Even though a lot of work went into the project, Tom hasn’t 
seen any of the (hopefully) completed work yet. Let’s see what 
he thinks about the completed website. 



What the heck is this? The site isn't 
anything like I thought it would be. 
You couldn't have taken a little more 
time and gotten it right? Ifs like you 
didiVt even know what I wanted... 


If your customer isn’t happy, you 
built the wrong software. 

Big bang software usually means working a 
whole lot, but it also means not showing the 
customer much until your work is done. The risk 
with that approach is you think you’re building 
what the customer wants with no real feedback 
until you think you’re finished. ^ - 


And, no matter how great YOU think your 
software is, it’s the customer you have to make 
happy. So if the customer doesn’t like what 
you’ve built, don’t waste time trying to tell them 
they’re wrong. Just get ready to do some rework. 

But how do you figure out what the customer 
really wants? It’s not always easy... 


喊 SI. 
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r^|^rpen 


your pencil 


Can you figure out where things went wrong? Below are three things Tom said 
he wanted his site to allow for. Your job is to choose the option underneath 
each item that most closely matches what Tom means. And for the third one, 
you’ve got to figure out what he means on your own. Good luck! 



Tom says, %% The customer should be able to search for trails." 


The customer should see a map of the world and then enter an address 
to search for trails near a particular location. 

The customer should be able to scroll through a list of tourist spots and 
find trails that lead to and from those spots. 

The customer should be able to enter a zip code and a level of difficulty 
and find all trails that match that difficulty and are near that zip code. 



Tom says, %% The customer should be able to order equipment/* 


The customer should be able to view what equipmentTom has and then 
create an order for items that are in stock. 

The customer should be able to order any equipment they need, but 
depending on stock levels the order may take longer if some of the 
items are back-ordered. 



Tom says, %% The customer should be able to book a trip.’’ 


v/Ka-t VOU 
七 Wmk so-f-twav-c 

should do Kcv*c- 



o 


Confused about what Tom really meant? 
It’s okay... just do your best. 

If you’re having a hard time figuring out which 
option to choose, that’s perfectly normal. Do 
your best, and we’ll spend a lot more time in this chapter talking 
about how to figure out what the customer means. 
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great software development is." 



Can you figure out where things went wrong? Your job was to choose the 
option underneath each item that most closely matches what Tom means. 
And for the third one, you had to figure out what he means on your own. 




A big question mark? Thafs your 
answer? How am I supposed to develop 
great software when I don’t even know 
for sure what the customer wants? 



If you’re not sure what the customer 
wants, or even if you think you’re sure, 
always go back and ask 

When it comes to what is needed, the customer is king. 
But it’s really rare for the customer to know exactly 
what he wants at the beginning of the project. 

When you’re trying to understand what your 
customer wants, sometimes there’s not even a right 
answer in the customer’s head, let alone in yours! If 
you disappear in a hurry and start coding, you may 
only have half the story... or even less. 

But software shouldn’t be guesswork. You need to 
ensure that you develop great software even when 
what’s needed is not clear up front. So go ask the 
customer what they mean. Ask them for more 
detail. Ask them for options about how you might 
implement about their big ideas. 


Software 
ctevelopment is 
NOT gfuesswork. 
You need to keep 
tke customer in 
tke loop to make 
sure you’re on 
tke rigfkt patk* 
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ftreat software development is... 

We’ve talked about several things that you’ll need for successful software. 
You’ve got the customer’s big ideas to deal with, their money you’re spending, 
and a schedule you’ve got to worry about. You’ve got to get all of those things 
right if you’re going to build consistently great software. 


Great software development delivers 




"the ^us-fcomcv- heeds, 

called the 

ih the hext 

Aap 七 ev* … 


What is needed ， 


tWt 如 sd 

赠 W be “sW. 



On 


Time ， 


and 



Budget 


Mo 七 tusWcv 

^ -(*OV W»OVC W^OYit^j 七 ha 灼 
Y/ds agreed ufoy\. 





Can you think of three examples of software 
you’ve been involved with where at least one of 
these rules was broken? 
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delivering with iteration 


ftettmg to the goal with ITERATION 

The secret to great software development is iteration. You’ve already seen that 
you can’t simply ignore the customer during development. But iteration provides 
you a way to actually ask the question, at each step of development, “How am I 
doing?” Here are two projects: one without iteration, and one with. 


Without iteration... 

Suppose you take the Big Bang approach to development — 
or any other approach where you’re not constantly checking 
in with the customer. The likely outcome? Missing what the 
customer wanted, and by a lot, not just a little. 




丁 he dcvclopmcht path 
you actually -took. ^ 


Start 



TV^c 70 ^ 

should V^avc taka 


S?^ 




With iteration... 

This time, you decide that every time you make significant 
progress you’ll check with the customer and refine 
what you’re working on. You also don’t make any major 
decisions without incorporating customer feedback. 


Time (or cavlv 

demo -to see 

tWmks. 




Start 



Just a -few days you dlav-i-fy 
v/hat the dus-fcomcv- mcaht wiih 
^ga\rd -to a dcirbih -Pcatuv-c. 
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-Pc3*tuV"CS i 


ted 

ih 


...and based ov\ 
made d -Pew 伙七 

desi^y\ 匕 isior\s 〜 


… 3hd 七 hdi 
3 -few moire 
a di-PfcirCh-t way -thdh 
ihe dus-tomc\r ih-tchdcd. 




/ 


/ 


/ 


But 七 b，you 
implcmcr\*tcd 3 

-fcaWc di-f-fevenly 

*bliay\ *bv^c ^us*tomc\r 

v-cally wa 士 d … 










〆 


/ 



■ ■ ■ 

t 

^ tV^c twe 70U delwev 
V ouv soRviavc, 70 U rt 

WAV ^ ^rom *tV^ 
tusWeA — 一也 


You jiavc^t bccr\ m 以七 ^ 

从 c and jap beWe^ 

七 heiv" ideal so-f*b>wav-c a^d wha 七 
youVe buildm^ is lav-jev-. 





The Goal 



^ou\r 


V^>u ^ould h^vc 
Wde the 
hd dc^isioh as 
showh above... 


...bu*b 扣 i-bcv-ation 
keeps you on *bra 乙 k 


r 





^W a di*Pfe\reh 乙 e 

r^akes/ y o 

Chd ?°'^i ahd wha-t the 
^usio^c\r was lookihg ^ 
^OhV C \rgc. Payday/ 


way till the Chd... 





The Goal 


Sowct'^cs, you v-c 
v\^V\"b oy\ *tva 乙 k, W 七 
vou iWatc ar^Y. I 七 
vc'm^ovdcs 七 V^a 七 4a 七 

youVe Y/ovk” 。灼 1 s 

dovvet 七 . 



Iteration is like a 
Ireejuent ckeckup 
lor your software. 
You’ll always know 
kow you’re doingf. 
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an iteration delivers working software 



Dumb Quest! 


9ns 


What if I’m sure that I know what 
the customer wants at the beginning of a 
project? Do I still need to iterate? 

Absolutely. Iteration and getting 
feedback from your customer is important 
especially when you think you know it all up 
front. Sometimes it can seem like a complete 
no-brainer on a simple piece of software, but 
checking back with the customer is ALWAYS 
worth it. Even if the customer just tells you 
you’re doing great, and even if you actually 
do start out with all the right requirements, 
iteration is still a way to make sure you’re 
on the right track. And, don’t forget, the 
customer can always change their mind. 

My entire project is only two 
months long. Is it worth iterating for such 
a short project? 

Yep, iteration is still really useful even 
on a very short project. Two months is a 
whopping 60 days of chances to deviate 
from the customer's ideal software, or 
misunderstand a customer’s requirement. 
Iteration lets you catch any potential 
problems like this before they creep into 
your project. And, better yet, before you look 
foolish in front of your customer. 


Ho matter kow tigf tke 
team, or kow long tke 
project, iteration is 

ALWAYS one ol tke 


keys to tuilctingf great 
soltware* 


Wouldn’t it just be better to spend 
more time getting to know what the 
customer really wants, really getting the 
requirements down tight, than always 
letting the customer change their mind 
midstream? 

You’d think so, but actually this is 
a recipe for disaster. In the bad old days, 
developers used to spend ages at the 
beginning of a project trying to make sure 
they got all the customer's requirements 
down completely before a single line of code 
or design decision was made. 

Unfortunately, this approach still failed. Even 
if you think that you completely understand 
what the customer needs at the beginning, 
the customer often doesn’t understand. So 
they’re figuring out what they want as much 
as you are. 

You need a way of helping your team and 
your customer grow their understanding 
of their software as you build it, and you 
can’t do that with a Big Bang, up-front 
requirements approach that expects 
everything to be cast in stone from day one. 

Who should be involved in an 
iteration? 

Everyone who has a say in whether 
your software meets its requirements, 
and everyone who is involved in meeting 
those requirements. At a minimum, that’s 
usually your customer, you, and any other 
developers working on the project. 


But I’m only a team of one, do I still 
need to iterate? 

Good question, and the answer is 
yes (starting to detect a theme here?). You 
might only be a development team of one, 
but when it comes to your project there are 
always, at a minimum, two people who have 
a stake in your software being a success: 
your customer and you. You still have two 
perspectives to take into account when 
making sure your software is on the right 
path, so iteration is still really helpful even in 
the smallest of teams. 

How early in a project should I start 
iterating? 

As early as you have a piece of 
software running that you can discuss with 
your customer. We normally recommend 
around 20 work days—1 calendar month, per 
iteration as a rule of thumb—but you could 
certainly iterate earlier. One- or two-week 
iterations are not unheard of. If you aren’t 
sure about what a customer means on 
Day 2, call them. No sense waiting around, 
guessing about what you should be doing, 
right? 

What happens when my customer 
comes back with bad news, saying I’m 
way off on what I’m building. What do I 
do then? 

Great question! When the worst 
happens and you find that you’ve deviated 
badly during an iteration, then you need to 
bring things back into line over the course of 
the next couple of iterations of development. 
How to do this is covered later on, but if you 
want to take a peek now, fast-forward to 
Chapter 4. 
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2.0 破 k” days is o^ly 
a ^u'»dcl»^c. You —Vvt 
c\\oost bo ^avc Icmyv 
sViov-tcv *»*tcra*t*ioir\s -fov- 
youv* pvojctt 


OK, I get it, iteration 
is important. But you said I should 
iterate every time I have working software, 
around every 30 calendar days, or 20 work 
days. What if I don’t have anything that can run 
after a month? What can I show the 

customer? 

An iteration produces working software 

With the old Big Bang approach to developing software, you Cohtmuous buildi d d 
probably wouldn’t have any software ready until the end f « hr, i o d * 
of the project, which is the worst time to realize that you’ve Chaptcv-s ahd 7 
gone wrong! 


or 


With iteration, you check every step of the way that you’re 
going in the right direction. That means making sure your 
software builds from almost day one (and more like hour 
one if you can manage it). You shouldn’t have long periods 
where code doesn’t work or compile, even if it’s just small 
bits of functionality. 



Then you show your customer those little pieces of 
functionality. It’s not much, sometimes, but you can still get 
an OK from the customer. 


f\ Y/ov-k'm^ build also 
makes a *to 

Youv 七 O’s ^rodufrbW 丨七 Y 
because Y ou dem’ 七 i^avc *to 

s^end someone 

clscs Code kc-fov-c you 

t 扣 y 七 。朽 ^ 70 吖。 w 

-tasks 


‘ s 


七 he Tow s 
has i\\t 

Y/orbV^ scc'rn^ 4a 七 


_ only 

Wb rt、 

"|ow\ 七 Wmks. 


Heading Placeholder 


Logo 


IIIKB 

oipib 


RAPT 


Main Content Area 
Placeholder 


你 got -to see wov-kih^ 

ahd ^adc 
some irwpov-taht 
dorwmehts you dould 
address Hght away. 


Hey, thafs looking good. 

But can we go with rounded tabs? 
Oh, and rd rather call it ''Get in 
touch" than 、、 Contact Us .〃 Last 
thing... can we add an option for 
''Order Status?" 


|hs*tead o*p buildih^ the Chtivc 
si*tc or\Ct) wc b\rokc the 
problem up srnallcv- dhuhks o( 
-fuhdtiohali-ty. Bath dhuhk thch 

be dcmohst\ratcd -to the ^sio^ 

separately. 
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an iteration is a complete development cycle 


Each iteration is a miwi - project 


With iteration, you take the steps you’d follow to build the entire project, 
and put those steps into each iteration. In fact, each iteration is a mini¬ 
project, with its own requirements, design, coding, testing, etc.，built right 
in. So you’re not showing your customer junk... you’re showing them well- 
developed bits of the final software. 


Think about how most software is developed: You gather requirements 
(what your customer wants), build a design for the entire project, code for a 
long time, and then test everything. It looks a bit like this: 

Wow lohj would it 
take -to bry av\d get 

B\/BRY \rc^ui\rcmch-t 

^ oh a big pv-ojedt? 


Ideas in.. 


► 


T 二， s 二 ㈣ # 


- - 

㈣ 工二 


♦ 



Requirements 


Design 



Each iteration is QUALITY software 


But suppose you didn’t look at iteration as just a way to 
write big software. Think of iteration as little cycles, where 
you’re gathering requirements, designing, writing code, 
and testing. Each cycle produces working, quality software: 


tY 0Kr 


Ideas in.. 


R 

D 

c 

T 




R 

D 

C 

T 











Dcsig, Code Test (^aVs Ao^t) 



itc\ratioh ^ohiaihs all -the 
S ^9 CS °*P ^ Complete p\rodcss. 
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ttc\rc it is...-the pa\rt whc\rc you 
w\ri"te cvc\ry lihe o( cvcv-y bit Jc 
-Puh^tiohali-ty. T0h/£ o-f ^odc- 


^oi all ^ 




(咖 啪你 ... 



So^-twav-c jc*b bijjcv- 
a^d move tomflc-tc …必 
ea^ *i*tcv-atioy\ ar\d also 
-fad*toV"S m 



Final Software Out 



Too late -to wkc 

dV\a^y s ^* s 
better be 崎七 . 


Final Software Out 


R 

D 

C 

T 



Y^i/ve checked "this saPlv/av^ a 七 
七 he cr>d o( every iievatio^, so 
then's a mu 匕 h bc-ttcv 七 his 

is v/li3"t "the dus"feorwC\r y/3>vts. 
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build a plan out of iterations and features 





It’s time to bring iterations into play on Tom’s Trails. Each of the features that Tom wants for Trails 
Online has had estimates added to specify how long it will take to actually develop. Then we 
figured out how important each is to Tom and then assigned a priority to each of them (10 being 
the highest priority, 50 being the lowest). Take each feature and position them along the project’s 
timeline, adding an iteration when you think it might be useful. 


y^ccd 




\ 



七七 Wis (caUrc 
•rt’s 







Bv\ i*tcva*t'ior\ av-ound 
2-0 v/ovkm^ d^ys i-f possible- 

乙 mor\*tKs 3r\d> 

\y\ 七 1 ^七 s rwoS't 2-0 

y/o\rkiy>^ days •… i*tcv*3*bioir\* 
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Oh, one other thing. Tom doesn’t want customers to be able to buy equipment unless they’ve logged in 
to the web site. Be sure and take that into account in your plan. 


Si 心). 



o IS high pirioiri-ty ; % is low. Wc\\ 
look ai why these pHoviiics ih 
of 10 m Chapin l. 



Pern ’ 七 <fo\ryt *to add as 
many i-tcv-atiohs as you 
{\\\v\V v/ill be useful. 
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deciding on a iteration tempo for your project 



Your job was to build an iteration plan for Tom’s Trails. You should have come 
up with something like we did, below: 


had "to put 3 lowcv" 


to put e 
f\rio\ri-ty -Pcatuv-c 
bcddusc ou\r lii^h pV"iov~i 七 y 

i 4 v 


•… pladc hcv-c, 


OY\C ， _ _ 



will ^ 

Sip ? 


fi_A 20 v/ovk^^ day- 

W vtcva 七咖 


u\r pv-ojc^*t C 灼 ds 

with By\ i*tcv-a*tioi^, 
whcvc *thc £.us*bomc\r 

yts *bo W si^ c^f-f 
wha 七 you’ve built 


cm 




^ wc did. 
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I decided to have the customer check 
on the project after each feature. 
Thafs even better than iterating every 
calendar month, right? 


Your iteration length should be at the 
right tempo for YOUR project 

An iteration helps you stay on track, and so you might decide to 
have iterations that are shorter or longer than 30 days. Thirty 
days might seem like a long time, but factor in weekends, and that 
means you’re probably going to get 20 days of actual productive 
work per iteration. If you’re not sure, try 30 calendar days per 
iteration as a good starting point, and then you can tweak for your 
project as needed. 




The key here is to iterate often enough to catch youself when 
you’re deviating from the goal, but not so often that you’re 
spending all your time preparing for the end of an iteration. It 
takes time to show the customer what you’ve done and then make 
course corrections, so make sure to factor this work in when you 
are deciding how long your iterations should be. 


thereiare no o 

Dumb Questl9ns 


Q/ The last feature scheduled for my iteration will push the 
time needed to way over a month. What should I do? 

Consider shifting that feature into the next iteration. Your 
features can be shuffled around within the boundaries of a 20-day 
iteration until you are confident that you can successfully build an 
iteration within the time allocated. Going longer runs the risk of 
getting off course. 

Ordering things by customer priority is all fine and 
good, but what happens when I have features that need to be 
completed before other features? 

When a feature is dependent on another feature, try to group 
those features together, and make sure they are placed within the 
same iteration. You can do this even if it means doing a lower-priority 
feature before a high-priority one, if it makes the high-priority feature 
possible. 


This occurred in the previous exercise where the “Log In” feature was 
actually a low customer priority, but needed to be in place before the 
“Buy Equipment” feature could be implemented. 

C^: If I add more people to the project, couldn’t I do more in 
each of my iterations? 

Yes, but be very careful. Adding another person to a project 
doesn’t halve the time it takes to complete a feature. We’ll talk more 
about how to factor in the overhead of multiple people in Chapter 2, 
when we talk about velocity. 

What happens when a change occurs and my plan needs 
to change? 

Change is unfortunately a constant in software development, 
and any process needs to handle it. Luckily, an iterative process has 
change baked right in...turn the page and see what we mean. 
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change happens 


The customer Will change things up 


Tom signed off on your plan, and Iteraton 1 has been completed. 
You’re now well into your second iteration of development and 
things are going great. Then Tom calls... 



Things are really starting to look great, 
but I had some thoughts after that last 
iteration. I think ifs really important that 
Tom's Trails Online has a mailing list, so my 
customers can communicate with each other. 




Rcmcmbcir, i-f youv so^iv/Src 
docs^i do what the ^us-tomcv 

广 youVc hot joihj -to 30 vevy 
^ ih dcvclopmchi 


Ifs up to you to make adjustments 

Tom’s new idea means three new features, all high-priority. 
And we don’t even know how long they’ll take, either. But 
you’ve got to figure out a way to work these into your projects. 


Join Mailing List 
Customer Priority 2' 






i Google Group 

ustomer Priority 20 


Wtrt avc 七 Wee 
Ws awev^ 七 all a 卜〜七 ^ 
oJf also. ?rtibj Wfoyrta^t. 


Put there are somcPIfr problems. 
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YouVc already a long way into development. 


V® u this ^a\r doy/h "the 
path "towav-ds deliveHh^ 
so^-twairc 


TV^c ovi—al 




You’ve been itcv-atm^ *to 
dim -fov* 七 he y>al … 



ttt 


and you've still got other features to build... 



and the deadline hasn't changed. 



Rcinr»c^bcir -the deddl'me 
•(Vom page 3? H 
hash 七 ^ha^ged, cvch 
"though Tom^s mihd kds. 


A li"L"tlc OVCV OhC 

州 oivth Uhtil -the 

TVail/l/Jix ^oh-Pcv-Chdc/ 
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handle change with iteration 


(well sort of) 


Iteration handles change automatically^ 


Your iteration plan is already structured around short cycles, and is 
built to handle lots of individual features. Here’s what you need to 


do: 



Estimate the new features 

First, you need to estimate how long each of the new features is going 
to take. We’ll talk a lot more about estimation in a few chapters, but for 
now, let’s say we came up with these estimates for the three new features: 



you add cstiwa*tcs -fov- 
V,oy/ tacM ^ 

haWc MU *to add. 



Have your customer prioritize the new features 

Tom already gave everything a priority of “20,” right? But you really 
need him to look at the other features left to implement as well, and 
prioritize in relation to those. 


Tom Att\dtd ^ 

tV.csc art move • 呵，十訌 

七 ‘ 七 haU IcH, 

o-tV^cv- -VcaWc a 

a 灼 dUa 灼 be w\%tA *m- 


Join Mailing List 
7 days 
Customer Priority 10 


Post to Mailings? 

2 days 

二 stomer Priority l 0 

Organize a Trekking Group 
10 days 

Customer Priority 20 


^ o( zo, relative io 

七略 hS 

幻 h spirmklc ohc move -fea-tuve ih 
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❺ 


Rework your iteration plan 

The ordering is set based on prioritization, and there aren’t any 
dependencies. So now you change your plan, keeping your iteration 
length and the overall schedule in mind. 


Buy 
Eqaip^ ent 
15 days 
10 




Search 
Trails 

3 cV^yslg 
PriX* 
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2 days 
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10 days 

pri. 20 
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t-i Organize a 


、dci a 


These lowcv* p\rio\ri*ty 
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上 — L 


days 
20 


ri 


■View 

Reviews 

■5 days 

pri. 20| 


Compare 

Trails 
1 day 


pn 


501 




o Check your project deadline 

Remember the TrailMix Conference? You need to see if the work 
you’ve got left, including the new features, still can get done in time. 
Otherwise, Tom’s got to make some hard choices. 


join Mailing List 
7 days 


P ° St to Mailing List 
2 days 

Organize a Trekking Groui 


Add a Review 
2 days 

Viei 
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Review, 

days 
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Search Trails 
3 days 
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(Days ol work lelt) 
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"this hurhbev* 
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use the right process for you 



You're about to hit me with a big fancy 
development process, aren’t you? Like if I 
use RUP or Quick or DRUM or whatever, 
Tm magically going to start producing 
great software, right? 


A process is really just a sequence of steps 


Process, particularly in software development, has gotten 
a bit of a bad name. A process is just a sequence of steps 
that you follow in order to do something — in our case, 
develop software. So when we’ve been talking about iteration, 
prioritization, and estimation, we’ve really been talking about 
a software development process. 


Rather than being any formal set of rules about what 
diagrams, documentation, or even testing you should 
be doing (although testing is something we’d definitely 
recommend!), a process is really just what to do, and when to 
do it. And it doesn’t need an acronym...it just has to work. 


We don’t really care what process you use, as long as it has 
the components that ensure you get great, quality software at 
the end of your development cycle. 


Tke 

software 

ctevelopment 

process lor YOU 
is one tkat kelps 

YOU develop 

and cteliver great 
software, on time 
and on budget. 

—- 一着 O 



It seems like iteration could be 
applied to any process, right? 


Iteration is more than a process 


Regardless of the actual steps involved in the 
process you choose, iteration is a best p 
It’s an approach that can be applied to any 
process, and it gives you a better chance of 
delivering what is needed, on time and 
on budget. Whatever process you end up 
using, iteration should be a major part. 
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great software development 


Your software iswl* complete until 
ifs been RELEASE? 


You added the new features, and now you and your team have finished 
the project on time and on schedule. At every step of the way, you’ve 
been getting feedback from the customer at the end of each iteration, 
incorporating that feedback, and new features, into the next iteration. 
Now you can deliver your software, and then you get paid. 


iWt blki， 9 about you^ 
^ you, 

⑽ about the 
^hhihg i h -the |rca| wovjd. 



Excellent. Tm already getting calls, and 
people love the new site. And our orders are 
up this week, mostly off of new customers 
that saw our online demo at TrailMix. 


Nice work. 


The Goal 

Itcv-atioh helped you 
dh ^dliievable goal 
that daptu\rcd what youv- 
^usiome\r heeded. 


tJiereic^e no ^ 

Dumb QuestiQns 


What happens when the customer comes up with new 
requirements and you can’t fit all the extra work into your 
current iteration? 

This is when customer priority comes into play. Your customer 
needs to make a call as to what really needs to be done for this 
iteration of development. The work that cannot be done then needs 
to be postponed until the next iteration. We’ll talk a lot more about 
iteration in the next several chapters. 

What if you don’t have a next iteration? What if you’re 
already on the last iteration, and then a top priority feature 
comes in from the customer? 


If a crucial feature comes in late to your project and you can’t 
fit it into the last iteration, then the first thing to do is explain to the 
customer why the feature won’t fit. Be honest and show them your 
iteration plan and explain why, with the resources you have, the work 
threatens your ability to deliver what they need by the due date. 

The best option, if your customer agrees to it, is to factor the 
new requirement into another iteration on the end of your project, 
extending the due date. You could also add more developers, or 
make everyone work longer hours, but be wary of trying to shoehorn 
the work in like this. Adding more developers or getting everyone 
to work longer hours will often blow your budget and rarely if ever 
results in the performance gains you might expect (see Chapter 3). 


you are here ► 
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you/* so 疗 ware development toolbox 




Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter ， 
you learned about several techniques to keep 
you on track. For a complete list of tools in the 
book, see Appendix ii. 




IWaW V>cl\>s YOU s-Uy bourse 






經纖 & 


Sonrte 

the key 

te 匕 hhi 气 ues you 

ih -this 
匕 hap*te\r … 


..ar,d some 
\^ost s . 


Developr»>ehi PHh^igU 

〜 W so^W e 祕 , eeded 

h 命 e 

⑸ or) bud9ei 


BUUET POINTS - 


■ The feedback that comes 
out of each iteration is the 
best tool for ensuring that 
your software meets the 
needs of your customers. 


■ An iteration is a complete 
project in miniature. 


■ Successful software is not 
developed in a vacuum. It 
needs constant feedback 
from your customer using 
iterations. 


■ Good software development 
delivers great software, on 

time and on budget. 

■ It’s always better to deliver 
some of the features 
working perfectly than all 
of the features that don’t 
work properly. 

■ Good developers develop 
software; great developers 
ship software! 
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great software development 



Software Development Cross 

Let’s put what you’ve learned to use and stretch out your 
left brain a bit. All of the words below are somewhere in 
this chapter. Good luck! 



Across 

2. I'm the person or company who ultimately decides if your 
software is worth paying for. 

4. Good Developers develop, great developers. 

6. An iteration produces software that is. 

7. Aim for.working days per iteration. 

9. The number of development stages that are executed within 
an iteration. 

12.1 am one thing that your software needs to do. 

13. The date that you need to deliver your final software on. 

15. Iteration is.than a process. 

16. The single most important output from your development 
process. 

17. Software isn't complete until it has been. 


Down 

I. A.is really just a sequence of steps. 

3. When a project fails because it costs too much, it is. 

5.1 contain every step of the software development process in 
micro and I result in runnable software. 

8. The minimum number of iterations in a 3 month project. 

10. Software that arrives when the customer needs it is. 

II. An iteration is a complete mini-. 

14. The types of software development projects where you 
should use iteration. 


you are here ► 
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exercise solutions 



Software Development Cross 
Solution 
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2 gcttWing recjpfrenients 


Knowing what the 




customer wants 





I know I said I wanted a Mustang, 
but I was really looking for the five- 
liter, turbocharged model... 


You can’t always get what you want...but the customer should! 

Great software development delivers what the customer wants. This chapter is all about 
talking to the customer to figure out what their requirements are for your software. 
You’ll learn how user stories, brainstorming, and the estimation game help you get 
inside your customer’s head. That way, by the time you finish your project, you’ll be 
confident you’ve built what your customer wants...and not just a poor imitation. 


this is a new chapter 
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orion’s orbits 


Oriow's Orbits is modernizmg 

Orion’s Orbits provides quality space shuttle services to discerning clients, but 
their reservation system is a little behind the times, and they’re ready to take 
the leap into the 21st century. With the next solar eclipse just four weeks away, 
they’ve laid out some serious cash to make sure their big project is done right, 
and finished on time. 

Orion’s doesn’t have an experienced team of programmers on staff, though, so 
they’ve hired you and your team of software experts to handle developing their 
reservation system. It’s up to you to get it right and deliver on time. 


ii 


We need a web site showing our current deals, and we want 
our users to be able to book shuttles and special packages, 
as well as pay for their bookings online. We also want to 
offer a luxury service that includes travel to and from the 
spaceport and accommodation in a local hotel... 


O 






How close do you think your final 
software will be to what the CEO of 
Orion Orbits wants? 
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gathering requirements 



rpen your pencil 


Hcv-c s erne *to 

yt Y ou 


Your job is to analyze the Orion’s CEO’s statement, and build some 
initial requirements. A requirement is a single thing that the software 
has to do. Write down the things you think you need to build for 
Orion’s Orbits on the cards below. 



Show cyrrcwt deals 

Description: 

$1)0w cyrrcwt deals to Qriows 

Orbits users. 



Rcrwcrwbcv*, should 

be a sJjjjlc ihmj the sys-tcrw has -fco 
do. 一 


you’ve got ihdex e^ards, 
"they Yt pc\r-fc^-t -Po\r y/vitih^ 
\rc^ui\rcmchts dovm. 


you are here ► 
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requirements start with customer ideas 

- Sharpen your pend — 

Solution 


Let’s start by breaking out the requirements from what the Orion’s 
Orbits CEO is asking for. Take his loose ideas and turn them into 
snippets, with each snippet capturing one thing that you think the 
software will need to do... 


Title: 


Show ourrewt deals 

Description: the web site will 

show current deals to OriQ^ 
0rWtsyser$. 


Title: 


look a shuttle 
Description ： Aw OrioM^ Orbits 
will be able to book a shuttle. 


Eadh dav-d 
dap*tu\rcs ov\t 
七 h’mg 七 he 

so^*twav-c v/ill 
/ y\ttd *to pv-ovidc. 


Title: 


JJookpMkMe 

Description ： An 0 rioOrbits ^ 

user will to book ^ special 
package with extras owliiic. 


Title: 


Pay online 
Description ： Am OrioMs Orbits 
user will be able to pay for their 
bookings onli»e 


Title: 


Arrawge travel 

Description: AW Qfi 她 Qf 咖鹏 f 

wHI M 费嫩忉 $ rr 柳狀打 付 

mi from the spaceport 


Title: 


Rookabotel 

Description: Aw Oriowls Orbits user 

will be able to book a hotel. 


thereiare no o 

Dumb Questi 9 ns 


Should we be using a specific 
format for writing these down? 

No. Right now you’re just grabbing and 
sorting out the ideas that your customer has 
and trying to get those ideas into some sort 
of manageable order. 


Aren’t these requirements just user 
stories? 

You’re not far off, but at the moment 
they are just ideas. In just a few more pages 
we’ll be developing them further into full- 
fledged user stories. At the moment it’s just 
useful to write these ideas down somewhere. 


These descriptions all seem really 
blurry right now. Don’t we need a bit 
more information before we can call them 
requirements? 

Absolutely. There are lots of gaps in 
understanding in these descriptions. To fill in 
those gaps, we need to go back and talk to 
the customer some more... 
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gathering requirements 


Talk to your customer to get 
MORE iwformatiow 

There are always gaps in your understanding of what your software is supposed to do, 
especially early in your project. Each time you have more questions, or start to make 
assumptions, you need to go back and talk with the customer to get answers to 
your questions. 

Here are a few questions you might have after your first meeting with the CEO: 


❶ 

❺ 

❺ 

O 

❺ 

o 


How many different types of shuttles does the software have to support? 


Should the software print out receipts or monthly reports (and what 
should be on the reports)? 

Should the software allow reservations to be canceled or changed? 

Does the software have an administrator interface for adding new types 
of shuttles, and/or new packages and deals? 


Are there any other systems that your software is going to have to talk to, 
like credit card authorization systems or Air/Space Traffic Control? 


Cayv Y ou u ? 

ay>o*t^CV 'uesW Y ow 
七 Y/ayrt ask 



OK, thanks for coming back to me. Til get to 
those questions in just a bit, but I thought of 
something else I forgot to mention earlier... 


Try to gather additional requirements. 

Talking to the customer doesn’t just give you a chance 
to get more details about existing requirements. You also 
want to find out about additional requirements the 
customer didn’t think to tell you about earlier. There’s 
nothing worse than finishing a project and the customer 
saying they forgot some important detail. 

So how do you get the customer to think of everything you 
need to know, before you start building their software? 




you are here ► 
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capturing what’s in your customer’s heads 


Pluesky with your customer 


When you iterate with the customer on their requirements, THINK BIG .Brainstorm 
with other people; two heads are better than one, and ten heads are better than two, as long as 
everyone feels they can contribute without criticism. Don’t rule out any ideas in the beginning- 
just capture everything. It’s OK if you come up with some wild ideas, as long as you’re all still 
focusing on the core needs that the software is trying to meet. This is called blueskying for 
requirements. 




\A/c tall *t^ ,s 

1 Ve 


^ dcvcl ^i i. 


The devdopev- 


y° u ihdludc the 
usevs 'themselves. 



Avoid office politics. 

Nothing will stifle creative bluesky 
thinking like a boss that won’t let people 
VV«I^n II * speak up. Try as much as possible to 

leave job descriptions and other baggage 
at the door when blueskying requirements. Everyone 
should get an equal say to ensure you get the most 
out of each brainstorming session. 



7^\ 


Ncvc\r -to mdludc the 

tus-tomcv- *m these sessions. 
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gathering requirements 


(^J^rpen your pencil 

T*^ lx ^ I I r i 


Take four of the ideas from the bluesky brainstorm and 
create a new card for each potential requirement. Also, 
see if you can come up with two additional requirements 
of your own. 


I/Ve Gh v-c-fcv- io 

easily by 
usihg its ti-tlc. 


Title: Pay with Yisa/MC/PaYPal 

Description: Users will be able to 

pay for their bQokiwgs by credit 
card. 
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getting more with role playing and observation 


Sometimes your bluesky session looks like this... 

Sometimes, no matter how hard you try, your bluesky sessions can be as muffled as a 
foggy day in winter. Often the people that know what the software should really do 
are just not used to coming out of their shell in a brainstorming environment, and you 
end up with a long, silent afternoon. 




...ahd o-thcirs will c\a^ uf dhd 
give you -the silent 




The zeyi of good requirements 

The key to capturing good requirements is to get 
as many of the stakeholders involved as possible. If 
getting everyone in the same room is just not working, 
have people brainstorm individually and then come 
together and put all their ideas on the board and brainstorm a bit 
more. Go away and think about what happened and come back 
together for a second meeting. 


Tkere are LOTS of 

ways to gatker good 
reejuirements. If one 
approack ctoesn’t work, 

simply m MOTHER, 
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gathering requirements 


Fiwd out what people REALLY do 

Everything (that’s ethical and legal) is pretty much fair game when 
you’re trying to get into your customer’s head to understand their 
requirements. Two particularly useful techniques that help you 
understand the customer are role playing and observation. 


Role playing 

If your customer is finding it hard to visualize how they need their software to work, act 
it out. You pretend to be the software and your customer attempts to instruct you in 
what they would like you to do. Then write down each thing the software needs to do 
on one of your requirement cards. 



And now I’d select the dates 
for the booking … 


O 


0 


OK, so now I display a calendar 
widget (and add display dates to 
my ''Create a booking" card...) 




the dhd ihes 

& do ihcivjob. 


Observation 


Sometimes the best way to understand how people will work with your software is to watch them, 
and figure out where your software will fit in. Nothing beats firsthand evidence, and observation 
can really help to bring out constraints and details that might have been missed in blue sky 
brainstorming or even in role playing. Also, try to observe the same interactions more than once ^^ 
with multiple observers so you don’t just gain one person’s impression of an event. 


Yes, we offer a selection of 
different types of seats... 


you iry 
people obsc\rvi h g oh 

扣 o“hd ihircc oUas\o^s 



Hmm y that requirement 
hasn*t come up before... 


Oo 


Tvv bo keef 70 ^ obsc\rva-b»o^ 

as uy^obWwc as ?oss\Wc. 
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customer-oriented requirements 

Our 

- your pencil 

Solution 


You should also v-olc 
play and observe- 


Your job was to take each of the ideas from the bluesky session on 
page 35 and create a new card for each potential requirement. 

h Jr\Oh-Puir>diiohal dohsivaihi, 
but it is still daptuved as a 
usev- s-fcovy 


Title: 


Pay with yisa/MC/FayPal 

Description: ... Users will be able to 

pay for their bookings by credit 
card or PayPal, 


Title: 


Order Flight PVP 

Description: A ⑽ erw 川 M 灿 ktQ 

order a PVP of a f light they have 
bceMOW,. 


Title: 


Support SfOOO concurrent 

users 


Title: 


Review flight 

Description: A USef WHIM 孩 Wfe 1*0 

leave a review for a shyttle flight 
they have been qw, 


Title: 


Order iw-f light meals 
Description: A user will be able to 

specify the meals avid driwks they 
wawt duriwg a f light. 


Description: The tT 孩 f f j(V f Qf 
Orbits is expected to reach ^OOO 
users, all using the site at the 
same time. 


vc ddded "to ou\r d^\rds 

^ page 11 a-Ptcv- tk 
b\raihS-to\rmihg with tKc dus-fcoi 




Title: 


^ookashuttle 


1C 


U P youvs Could 
have beeh 



Title: 


Use Ajax for ihe UV 

OescHption, 

wUl 时 eAiMte 咖咖 P 中 

p_deawol 錄 1$ 歐⑽ 1 賴 
experience. 


Title 


Choose seMiwg 

Description: A user will be able to 
choose aisle or window seatihg, 


“vc added 

诎⑽》七心 u^ovcvcd 

vole ov 

okscv-vatioy\. 


These are really 
looking good, but whafs Ajax? 
Isn’t that a kitchen cleaner or 
something? 


The boss ish’t suve he M 

Uhdc\rs-tahds what this — ^ 
\rc<\ui\rcmcht is a\\ about- 




7m 
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gathering requirements 


Your requircmcwts must be CUSTOMER-oricwtcd 

A great requirement is actually written from your customer’s perspective 
describing what the software is going to do for the customer. Any requirements that 
your customer doesn’t understand are an immediate red flag, since they’re not things that 
the customer could have possibly asked for. 


A requirement should be written in the customer’s language and read like a user story: 
a story about how their users interact with the software you’re building. When deciding 
if you have good requirements or not, judge each one against the following criteria: 


User stories SHOULD 


參#參 


Yo\a should be 
able "to 

box -Pov 
o-p you\r 
uscv- s-fco\rics. 


□ 

□ 

□ 

□ 


,• describe one thing that the software needs to do for the customer. TWmk ^ ^ 

■CAAstowCV, 1。', 

be written using language that the customer understands. ^ 

^ TWis mca^s i\\c 

... be written by the customer . 々 ^ ^,ves o 灼 e, 妁 o 眯 attev* 

y/\^o s£.v*ibklcs ov\ 3 y\o*tc6avd- 


... be short. Aim for no more than three sentences. 


User stories SHOULD NOT … 


□ 

□ 

□ 


... be a long essay. - 

... use technical terms that are unfamiliar to the customer. 
... mention specific technologies. 


/( sWy is loh 9； 

you should t\ry ahd 

^cak \i up M U | 七 ip | e 

^allcir uscir sWics Gcc 
page ^ -fov- -tip s ) 


Title . Use Ajax for the UV 

oes ； ri ption ： The^eri^oe 

provide a oqoUiwU 敝 owlme 
cxperieifice. 


This dav-d is B uscir 

s*to\ry a 七 all; it’s vcally a 
dcsijh dedisioh- Save i*t 
(or la-tcv-, you s-ta\rt 

irwplcrwchtmj the so^ty/av-c. 





DESIGN IDEAS 


A user story is 
written from tke 

CUSTOMERS 

PERSPECTIVE, 

Botk you AND your 
customer skould 
understanct wkat a 
user story means. 
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keep your customer in the loop 


O 



Great, so now youve created more user stories, 
and gotten a bunch more questions. What do you do 
with all these things you re still unclear about? 


Ask the customer (yes ， again). 

The great thing about user stories is that it’s easy for both you and 
the customer to read them and figure out what might be missing. 

When you’re writing the stories with the customer, you’ll often 
find that they say things like “Oh, we also do this".’’，or “Actually, 
we do that a bit differently".’’ Those are great opportunities to 
refine your requirements, and make them more accurate. 

If you find that you are unclear about anything, then it’s time 
to have another discussion with your customer. Go back and 
ask them another set of questions. You’re only ready to move 
on to the next stage when you have no more questions and 
your customer is also happy that all the user stories capture 
everything they need the software to do — for now. 


tJiereiare no ^ 

Dumb Questi9ns 


Q/ What’s the “Title” field on my user 
stories for? Doesn’t my description field 
have all the information I need? 

The title field is just a handy way to 
refer to a user story. It also gives everyone 
on the team the same handy way to refer 
to a story, so you don’t have one developer 
talking about “Pay by PayPal，” another 
saying, “Pay with credit card,” and find out 
they mean the same thing later on (after 
they’ve both done needless work). 

Won’t adding technical terms 
and some of my ideas on possible 
technologies to my user stories make 
them more useful to me and my team? 


No, avoid tech terms or technologies 
at this point. Keep things in the language 
of the customer, and just describe what 
the software needs to do. Remember, the 
user stories are written from the customer's 
perspective. The customer has to tell you 
whether you’ve gotten the story right, so 
a bunch of tech terms will just confuse 
them (and possibly obscure whether your 
requirements are accurate or not). 

If you do find that there are some possible 
technical decisions that you can start to add 
when writing your user stories, note those 
ideas down on another set of cards (cross 
referencing by title). When you get to coding, 
you can bring those ideas back up to help 
you at that point, when it’s more appropriate. 

And I’m supposed to do all this 
refining of the requirements as user 
stories with the customer? 


Yes, absolutely. After all, you’re 
only ready for the next step when both 
you and the customer finally decide that 
you completely understand the software 
requirements. You can’t make that decision 
on your own, so keeping your customer in 
the loop is essential. 

This seems like a lot of 
requirements work up front at the 
beginning of the project. What about 
when things change? 

The work you’ve done so far is just 
your first attempt at gathering requirements 
at the beginning of your prject. You’ll 
continue to refine and capture new 
requirements throughout your project, 
feeding those requirements where necessary 
into your project’s iterations. 
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gathering requirements 


develop your requirements with customer feedback 


The steps we’ve followed so far have been all about coming to grips with the customer’s ideas and 
refining those ideas into user stories. You execute these steps, in one form or another, at the beginning 
of each iteration to make sure that you always have the right set of features going into the next 
iteration. Let’s see how that process currently looks... 


❻ Blue sky Brainstorming 


Rcrwcrwbcv-, -this p\rodcss happens ai 
"the o( v\oi 

jus*t the o( you\r 


Finding holes and adding clarity on 
details using the customer’s feedback 


TW^s ^oa\ at 
tW»s stay. 


Constructing User Stories 



rl add , ^ My these 

忪。 u 3 Wt yo 叱 

iWi 雛 




Clear, customer-focused user stories 
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user stories capture what your software needs to do 



Usev Stovy Exyosedi 

This week’s interview: 

The many faces of a User Story 


Head First ： Hello there, User Story. 

User Story ： Hi! Sorry it’s taken so long to get an 
interview, I’m a bit busy at the moment... 

Head First ： I can imagine, what with you and your 
friends capturing and updating the requirements for 
the software at the beginning of each iteration, you 
must have your hands pretty full. 

User Story ： Actually, I’m a lot busier than that. I 
not only describe the requirements, but I’m also the 
main technique for bridging the gap between what 
a customer wants in his head and what he receives 
in delivered software. I pretty much drive everything 
from here on in. 

Head First ： But don’t you just record what the 
customer wants? 

User Story ： Man, I really wish that were the case. 
As it turns out, I’m pretty much at the heart of an 
entire project. Every bit of software a team develops 
has to implement a user story. 

Head First ： So that means you’re the benchmark 
against which every piece of software that is 
developed is tested? 

User Story ： That means if it’s not in a user story 
somewhere, it ain’t in the software, period. As you 
can imagine, that means I’m kept busy all the way 
through the development cycle. 

Head First ： Okay, sure, but your job is essentially 
done after the requirements are set, right? 

User Story ： I wish. If there’s anything I’ve learned, 
requirements never stay the same in the real world. I 
might change right up to the end of a project. 


Head First ： So how do you handle all this pressure 
and still keep it together? 

User Story ： Well, I focus on one single thing: 
describing what the software needs to do from the 
customer’s perspective. I don’t get distracted by the 
rest of the noise buzzing around the project, I just 
keep that one mantra in my head. Then everything 
else tends to fall into place. 

Head First ： Sounds like a big job, still. 

User Story ： Ah ， it’s not too bad. I’m not very 
sophisticated, you know? Just three lines or so of 
description and I’m done. The customers like 
me because I’m simple and in their language, 
and the developers like me because I’m just a 
neat description of what their software has to do. 
Everyone wins. 

Head First ： What about when things get a bit more 
formal, like with use cases, main and alternate flows, 
that sort of thing? You’re not really used then, are 
you? 

User Story ： Heck, I can smarten myself up with 
some more details to be a use case if that’s what you 
need, and lots of people do dress me up that way 
for their bosses. The important thing is that we all 
describe what a piece of software needs to do, no 
matter how we look. Use cases are more or less user 
stories in a tuxedo. 

Head First ： Well, you heard it here first folks. Next 
week we’ll be catching up with Test to see how he 
guarantees that software does what a user story 
requires. Until then, take care and remember, always 
do only what your user story says, and not an ounce 
more! 
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gathering requirements 


User stories define the WHAT of your project, 
estimates define the WHEN 

After your initial requirement-capture stage you will have a set of clear, 
customer-focused user stories that you and the customer believe capture 
WHAT it is you’re trying to build, at least for the first iteration or so. 

But don’t get too comfortable, because the customer will want to know 
WHEN all those stories will be built. 

This is the part where the customer asks the big question: How long 
will it all take? 


0 


Hmm, great. Now what do I do? How do I 
figure out how long everything is going to take 
when all I have so far is a pack of user stories? 


o 



Your project estimate is the sum of the 
estimates for your user stories 

To figure out how long it will take to complete all of 
the requirements captured in your user stories, you 
need to use a two-step process. 

I-P you yt 七 his 
-Pigu\rcd out ^ 

Add an estimate to each user story for how long you think it 
will take to develop (that is, design, code, test, and deliver) 
that functionality. 


You need to: 


Add up all the estimates to get a total estimate for how long 
your project will take to deliver the required software. 

tWis wll be a 

p'icdc o-f take- 
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estimates come with assumptions 



E%eRci$e 


Welcome to the Orion’s Orbits Development Diner. Below is the menu...your job is to choose 
your options for each dish, and come up with an estimate for that dish—ahem—user story. 
You'll also want to note down any assumptions you made in your calculations. 


fUTRQSS 


□ - - 

Pay Credit Card or Paypal 

Visa. 2 da y s 

Mastercard. 2 days 

PayPal. 2 days 

American Express. 5 days 

□ --- 

Order Flight DVD 

Stock titles with standard 
definition video. 2 days 

Provide custom titles. 5 days 

High Definition video. 5 days 

__ □ 

Choose Seating 

Choose aisle or 

window seat. 2 days 

Choose actual seat 

on shuttle. 10 days 

Order ln_Fliglit Meals 

Select from list of three meals 
& three drinks. 5 days 

Allow special dietary needs 
(Vegetarian, Vegan). 2 days 


Dsssqrts 


J" 

L 

Create Flight Review 

Create a review online. 

… 3 days 

Submit a review by email.. 

… 5 days 
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Title ： Pay with Yisa/MC/FayPal 

Description: Users will be able to 

pay for their bookings by credit 
csrd or. PayPal ， . 


Title 


Order Flight PVP 

Description: A user will be aWc to 

order a PVP of a f light they have 
beewow. 


Title: Choose 

Description ： A ⑽ erwHIM 碍 eto 

choose aisle or window seating- 


Title ： Order in-flight meals 
Description: A user will be able to 

specify the meals awddriwks they 
wawiduriwg a f light. 


Title 


Review flight 
Description ： A user will be a We to 
leave a review for a shuttle flight 
they have beew ow, 


Estimate for each 
ser story in days 


[ . 

i*te youv cs-twa-tc 
U -tV^c usev s^Y 


Jot doy/h ahy^ assurhp-ti 
you thihk youVc 
•m you\r estimate. 


Ohs 



Assumptions? 
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assumptions kill confidence in your user stories 



What did you come up with? Rewrite your estimates here. Bob and Laura also did 
estimates...how did yours compare to theirs? 

Your estimates Bob’s estimates Laura’s estimates 


Purt Y owV， cs-twa-tcs V^cvc. 






酽 _***___， 


10 












IZ 


■ 圓 ■_■■■! 




z 


L ■■ 圓 ■ 酬 ■ 國 >__J 





WcW, ai least we 了 

seonn -fco ag\rcc hc\rc— 





It looks like everyone has a different idea for 
how long each user story is going to take. 
Which estimates do you think are RIGHT? 
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gathering requirements 


Cubicle conversation 



So Laura, we catVt both be totally 
wrong. But how did we get such 
completely different estimates? 


Laura: Well, let’s start with the first user story. How did you come up with 10 
days? 

Bob: That’s easy, I just picked the most popular credit cards I could think of, and 
added time to support PayPal... 

Laura: But lots of high-end executives only use American Express, so my 
assumption was that we’d have to cope with that card, too, not just Visa and 
MasterCard. 

Bob: Okay, but I’m still not feeling entirely happy with that. Just that one 
assumption is making a really big difference on how long it will take to develop 
that user story... 

Laura: I know, but what can you do, we don’t know what the customer expects... 

Bob: But look at this...you came up with 20 days for “Ordering a Flight DVD,” 
but even with all the options, that should be 14 days, max! 

Laura: I was actually being on the conservative side. The problem is that creating 
a DVD is a completely new feature, something I haven’t done before. I was 
factoring in overhead for researching how to create DVDs, installing software, and 


Getting rid oi 
assumptions 
is tke most 


getting everything tested. Everything I thought I’d need to do to get that software 
written. So it came out a lot higher. 

Bob: Wow, I hadn’t even thought of those things. I just assumed that they’d been 
thought of and included. I wonder if the rest of the estimates included tasks like 
research and software installation? 

Laura: In my experience, probably not. That’s why I cover my back. 


important 
activity lor 
coming up witk 
estimates you 
Relieve in. 


Bob: But then all of our estimates could be off... 

Laura: Well, at least we agree on the “Create a Flight Review” story. That’s 
something. 

Bob: Yeah, but I even had assumptions I made there, and that still doesn’t take 
into account some of that overhead you were talking about. 

Laura: So all we have are a bunch of estimates we don’t feel that confident about. 
How are we going to come up with a number for the project that we believe when 
we don’t even know what everyone’s assumptions are? 


you are here ► 


47 





highlighting assumptions and obtaining confident estimates with planning poker 


Playmg planning poker 


To come up with accurate estimates, you need to get rid of all those assumptions that put 
your estimates at risk of being wrong. You want a set of estimates that everyone believes in 
and are confident that they can deliver, or at the very least you want a set of estimates that let 
you know what assumptions everyone is making before you sign on the dotted line. It’s time 
to grab everyone that’s going to be involved in estimating your user stories, sit them around a 
table, and get ready to play “planning poker.’’ 


Place a user story in the middle of the table 

This focuses everyone on a specific user story so they can get their heads around 
what their estimates and assumptions might be. 


Title: Pay with Visa/MC/PayPal 

Description: ... Users will be able to 

pay for their bookings by credit 
card or PayPal. 




^ a solid estimate 4 
how lo,g it wi „ ^ ^ dcV( 

th,s S W 

Should 工， 


O 


Everyone is given a deck of 13 cards . Each card has an 
estimate written on one side. 

You only need a small deck, just enough to give people several options: 


TW»s card 
W |ts 

alv-cad^ dov\t- 



Ml these 

cst>w3"tcs 3VC 

d —伏卿 (w 

davs 

-t>,o 、s 細 

W da— 


Evc\ryohc has cadh these ta^rds. 


Hrwrurn … 如 y -thouglrts ov\ what it 
rwca^s i-p somcohC flays ohC these 
^a\rds -Po\r theiv- estimate? 


P) n L ^ playcir uses 

.六 io / ou ^ Uc a ^ eak ^ 

pht ^Side^r usm 9 « 仏也 3 “ a bit 


♦ 4 **' 

拳 * 
拳峰 ♦* 


o 
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gathering requirements 


❷ 


Everyone picks an estimate for the user story and places the 
corresponding card face down on the table. 

You pick the card that you think is a reasonable estimate for the user story. 
Don’t discuss that estimate with anyone else, though. 


Alakc su\rc youv* 
cs-timatc is -pov 
the whole uscv- 
S'tov-y, hot just 

a pav-t o( ii 


Plate 70 ^ 

so 70 U ^ ■ 

\/ r «p wouv* 
tol eve^ce else 



Pay with Yisa/MC/FayFal 
1 ： Users will be able to 


C/Tj 


, GO 


The useir sio^ry 

is s iill ih ih c 
^ddl C ... siiH 
七 h TO^US. 


o 


Everyone then turns over their cards at exactly the same time 

Each player at the table shows their hand, which gives their honest estimate 
for the user story. 

■ Tit_ e: Fay with Yisa/MC/PayPal V 

Description ： Users wiJI be able to I %/) 

■ ■ pay fortbeir bookings by credit I U 

! 7 I I ^ ^ 

? e : ::仏 

v. _ 



參 I 黎 


❺ 



The dealer marks down the spread across each of the estimates. 

Whoever is running the game notes the spread across each of the estimates that 
are on the cards. Then you do a little analysis: 


L^Uyj oJfe *to -fioiuvc 



ihis 

loo c 


The larger the difference between the estimates, the Jess confident you 
are iw the estimate, awd^the wore assumptions you need to root out. 
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assumptions are killed or become risks 



How does this help with assumptions? 
And what about that guy who chose 
100? We can’t just ignore him, can we? 


Large spreads can be a misunderstanding 

When you see large gaps between the estimates on a particular 
user story’s spread, something is probably missing. It could be 
that some of your team misunderstood the user story, in which 
case it’s time to revisit that story. Or it could be that some 
members of your team are just unsure of something that another 
part of your team is completely happy with. 

In either case, it’s time to look at the assumptions that your team 
is making and decide if you need to go back and speak to the 
customer to get some more feedback and clarification on your 
user stories — and the assumptions you’re making about them. 

In fact, even if everyone’s estimate is within the same narrow 
range, it’s worth asking for everyone’s assumptions to make sure 
that EVERYONE is not making the same wrong assumption. 

It’s unlikely that they are, but just in case, always discuss and 
document your assumptions after every round of planning poker. 

t 

TVy v/iritihg youv 

assump-tiohs oh the ba 匕 k 

y oWr ^ siory c,avds. 
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Put assumptions on trial for their lives 

When it comes to requirements, no assumption is a good 
assumption. So whenever planing poker turns up your team’s 
assumptions, don’t let that assumption into your project without first 
doing everything you can to beat it out of your project... 


Put every assumption on trial 

You’re aiming for as few assumptions as possible 
when making your estimates. When an assumption 
rears its head in planning poker, even if your entire 
team shares the assumption, expect that assumption to 
be wrong until it is clarified by the customer. 




opposed "to ho-fc khow'mg what 
you d。"’ 七 k how … 


At least you know what you don’t know 

No matter how hard you try, some assumptions really will survive clarification with 
the customer. That’s OK. Sometimes the customer doesn’t have a great answer to 
a particular assumption at the beginning of a project, and in those cases you need 
to live with the assumption. The important thing is that you know that there is an 
assumption being made, and you can write it down as a risk for that user story (like on 
the back of your user story card). This helps you keep an eye on and track your risks, 
knocking them out at a later stage in your project. 


70 ^ 州吵七〜⑼ 
ac6.de \x> delay 
dcvclofwcv\*t o\ a uscy 
/減心 a o 

suWW'm^ assumptions wtU 


Wkile you can’t always get rid ol all 
assumptions，tke goal cturing estimation 
is to eliminate as many assumptions as 
possible clarifying tliose assumptions 
witli tire customen Any surviving 
assumptions tken become risks. 
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use your customer effectively 


With all this talk of customer 
clarif ication, it seems to me that you could 
be bothering the customer too much. You 
might want to think about how you use the 
customers time effectively... 



Value your customer’s time. 

Putting all your asssumptions on trial for their life and seeking 
clarification from the customer can become a lot of work. You can 
easily spend a lot, if not all, of your time with your customer. That 
might be OK with some customers, but what about the ones that are 
too busy to talk with you every 15 minutes? 

In those cases you need to use your customer’s time carefully. Even 
though you’re trying to make sure you’ve gotten things right on their 
project, you don’t want to come across as being not up to the job. So 
when you do spend time with your customer, make sure that time is 
organized, efficient, and well-spent. 

Try gathering a collection of assumptions together and then clarifying 
those all at once with the customer. Rather than bothering the 
customer at the end of every round of planing poker, schedule an 
assumption-busting session where you take in the collected 
assumptions and try to blast as many of them away as possible. 


Once you have your answers, head back for a 
final round of planning poker. 

Once you’ve gotten a significant number of your assumptions 
beaten out in your assumption-busting session with the customer, 
it’s time to head back and play a final round of planning poker 
so that you and your team can come up with estimates that 
factor in the new clarifications. 
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Why is there a gap between 40 and 
100 days on the planning poker cards? 

Well, the fact is that 40 is a pretty 
large estimate, so whether you feel that the 
estimate should be 41 or even 30 days is 
not really important at this point. 40 just says 
that you think there's a lot to do in this user 
story, and you’re just on the boundary of not 
being able to estimate this user story at all... 

100 days seems really long; that’s 
around half a year in work time! Why have 
100 days on the cards at all? 

譬 

• Absolutely, 100 days is a very long 
time. If someone turns up a 100-days 
card then there’s something seriously 
misunderstood or wrong with the user story. 

If you find that it’s the user story that’s 
simply too long, then it’s time to break that 
user story up into smaller, more easily 
estimatable stories. 

What about the question-mark 
card? What does that mean? 

That you simply don’t feel that you 
have enough information to estimate this 
user story. Either you’ve misunderstood 
something, or your assumptions are so big 
that you don’t have any confidence that any 
estimate you place down on the table could 
be right. 

Some people are just bound to pick 
nutty numbers. What do I do about them? 

Good question. First, look at the trends 
in that individual's estimates to see if they 
really are being “nutty,” or whether they in 
fact tend to be right! However, some people 
really are inclined to just pick extremely high 
or very low numbers most of the time and 



get caught up in the game. However, every 
estimate, particularly ones that are out of 
whack with the rest of the player’s estimates, 
should come under scrutiny after every 
round to highlight the assumptions that are 
driving those estimates. 

After a few rounds where you start to realize 
that those wacky estimates are not really 
backed up by good assumptions, you can 
either think about removing those people 
from the table, or just having a quiet word 
with them about why they always insist on 
being off in left field. 

Should we be thinking about who 
implements a user story when coming up 
with our estimates? 

No, every player estimates how long 
they think it will take for them to develop 
and deliver the software that implements the 
user story. At estimation time you can’t be 
sure who is going to actually implement a 
particular user story, so you’re trying to get 
a feel for the capability of anyone on your 
team to deliver that user story. 

Of course, if one particular user story is 
perfect for one particular person’s skills, then 
they are likely to estimate it quite low. But 
this low estimate is balanced by the rest of 
your team, who should each assume that 
they are individually going to implement that 
user story. 

In the end, the goal is to come up with an 
estimate that states “We as a team are all 
confident that this is how long it will take any 
one of us to develop this user story.” 

Each estimate is considering more 
than just implementation time though, 
right? 

Yes. Each player should factor in how 
much time it will take them to develop and 


deliver the software including any other 
deliverables that they think might be 
needed. This could include documentation, 
testing, packaging, deployment—basically 
everything that needs to be done to develop 
and deliver the software that meets the user 
story. 

If you’re not sure what other deliverables 
might be needed, then that’s an assumption, 
and might be a question for the customer. 

What if my team all agree on 
exactly the same estimate when the cards 
are turned over. Do I need to worry about 
assumptions? 

Yes, for sure. Even if everyone agrees, 
it’s possible that everyone is making the 
same wrong assumptions. A large spread 
of different estimates indicates that there 
is more work to be done and that your 
team is making different and possibly large 
assumptions in their estimates. A tiny spread 
says that your team might be making the 
same assumptions in error, so examining 
assumptions is critical regardless of the 
output from planning poker. 

It’s important to get any and all assumptions 
out in the open regardless of what the 
spread says, so that you can clarify those 
assumptions right up front and keep your 
confidence in your estimates as high as 
possible. 

Don’t make 
assumptions: about 
your assumptions •“ 
talk akout 

EVERYTHING. 
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keep estimates smaH 


A Plft user story estimate is 
a user story estimate 


"tW«S 

Jfvom 加 ― I? 



you have -to have 
estimates like 
"this, thch you heed 

h> be talk” as a 

team as o-Ptch as 


7 


possible. IVcII get io 
that ih a -Pew 


We all agree, we don’t need any 
more information. This user story 
will take 40 days to develop... 


Your user story is too big. 

40 days is a long time, and lots can change. 
Remember, 40 days is 2 months of work time. 

An entire iteration should ideally be around 
1 calendar month in duration. Take out 
weekends and holidays, and that’s about 20 
working days. If your estimate is 40 days for 
just one user story, then it won’t even fit in one 
iteration of development unless you have two 
people working on it! 

As a rule of thumb, estimates that are longer 
than 15 days are much less likely to be accurate 



than estimates below 15 days' l •丄 i i i . 

7 \ 七沉 sow people believe that 

cs-tinr\a*tcs loh^cv- thah seveh days 
should be doublc-^hc^kcd. 


Whew a user story's estimate breaks the 
15 - day rule you caw either: 



Break your stories into smaller, more easily 
estimated stories 

Apply the AND rule. Any user story that has an “and” in 
its title or description can probably be split into two or 
more smaller user stories. 



^ 一 S-tavt'mg -fco schsc 

Talk to your customer...again. 3 pattev-h? 

Maybe there are some assumptions that are pushing 
your estimate out. If the customer could clarify things, 
those assumptions might go away, and cut down your 
estimates significantly. 


Estimates greater 
tkan 15 ctays per 
user story allow too 
muck room for error* 

Wken an estimate is 
too long, apply tke 
AND rule to break 
tke user story into 
smaller pieces. 
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The two user stories below resulted in estimates that broke the 15-day rule. Take the two 
user stories and apply the AND rule to them to break them into smaller, more accurately 
estimatable stories. 


Title 


Choose seating 

Description: A user will choose 

aisle or wiwdow seMiw9. be able 
ta select the seat they want and 
chawgc that scat UP to 24 hours 
before the flight. 


Title: 

Description: 


Title: 

Description: 


Title: Order iw-f light meals 

Description ： A user will choose 
which meal option they want 
什 ， a choice of three, md be able 
to iiidicatc if they are yegetariaM 
pryegaM. 


Title: 

Description: 


Title: 


Description: 






Title: 



Title: . 

Description: 

Description:. 
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aim for estimates you and your team believe in 



E^e(u：tSe 

SoLytiOH 


Your job was to take the longer user stories at the top of each column and turn them into 
smaller, easily estimatable user stories. 


Title 


Choose seating 

Description: A user will choose 

aisle or wiwdow seMiw9. be able 
ta select the seat they want and 
chawgc that scat UP to 24 hours 
before the f light. 


^tie ： Choose arsle/wmdow$eat 
Description ： A user caw choose 
either aisle or window seat ! 雛 


Tine ： C boose $p ccific scat 

Description: A user caw choose the 

actual seat that they want for a 
shuttle flight. 


Title ： Change seating 

Description: A US6F C9M ChdMQG 

their seat up to 24 hours before 
launch, provided other seat 

QPtkm$ are 覆糾础 1 ?， 




■nti e: Order in-flight meals 

Description: A USef Will CHOOSC ； 

which meal option they wawt 
什 ， a choice of three, mAM able 
to iiidicate if they are yegetariaM 
pryegaM. 


Title: Select from meal options 

Description: ... A user caw choose 

the meal they wawt from a set of 
three weal optiQWS, 


Title ： Specify vegetar ian weal 

Description: A US8f Will feg aWC! tO 

indicate that they are vegetaria» 
whew selecting tkir meal optioM. 


Title: 


Specif y vegan meal 

Description: A user will be able 

to mdlcate that they are vegaii 
whew selectiwg their weal options, 
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gathering requirements 


The goal i$ cowvgrggwcg 

After a solid round of planning poker, you should not only have estimates 
for each user story but be confident in those estimates. The goal now is to 
get rid of as many assumptions as possible, and to converge all of the 
points on each user story’s spread of estimates. 


TV^csc esWate a 代 

dlosc *to or\t 3 ^o*bV^CV"- 



Run through this cycle of steps till you reach a consensus: 


O 

@ 

o 

o 


Talk to the customer 


First and foremost, get as much information and remove as many assumptions 
and misunderstandings as possible by talking to your customer. 


Play planning poker 

Play planning poker with each of your user stories to uproot any hidden 
assumptions. You’ll quickly learn how confident you are that you can 
estimate the work that needs to be done. 



S 二 ㈣ 。 7 


Clarify your assumptions 

Using the results of planning poker, you’ll be able to see where your 
team may have misunderstood the user stories, and where additional 



clarification is needed. 

Come to a consensus 

Once everyone’s estimates are close, agree on a figure for the user 
story’s estimate. 


|-t also be useful *to 

⑽ tc He U, 
ad W— estimates ^ 

awe vou 

best a^di >wo\rst tasc 


How close is "close enough"? 


stc^av'»os. 


Deciding when your estimates are close enough for consensus is really up to you. 
When you feel confident in an estimate, and you’re comfortable with the 
assumptions that have been made, then it’s time to write that estimate down on 
your user story card and move on. 
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your estimates are your promise 



Dumb Quesd 


ons 


How can I tell when my estimates are close enough, 
and have really converged? 

Estimates are all about confidence. You have a good 
estimate if you and your team are truly confident that you can 
deliver the user story’s functionality within the estimate. 

I have a number of assumptions, but I still feel 
confident in my estimate. Is that okay? 

Really, you should have no assumptions in your user 
stories or in you and your team’s understanding of the customer’s 
requirements. 

Every assumption is an opportunity to hit unexpected problems 
as you develop your software. Worse than that, every assumption 
increases the chances that your software development work will 
be delayed and might not even deliver what was required. 

Even if you’re feeling relatively confident, knock out as many of 
those assumptions as you possibly can by speaking to your team 
and, most importantly, speaking to your customer. 

With a zero-tolerance attitude to assumptions, you’ll be on a 
much more secure path to delivering your customer the software 
that’s needed, on time and on budget. However, you will probably 
always have some assumptions that survive the estimation 
process. This is OK, as assumptions are then turned into risks 
that are noted and tracked, and at least you are aware of those 
risks. 


Your estimates are your 

PROMISE to your customer 

about kow long it will take you 
and your team to DELIVER* 


I’m finding it hard to come up with an estimate for my 
user story, is there a way I can better understand a user story 
to come up with better initial estimates? 

First, if your user story is complicated, then it may be too 
big to estimate confidently. Break up complex stories into simpler 
ones using the AND rule or common sense. 

Sometimes a user story is just a bit blurry and complicated. 

When that happens, try breaking the user story into tasks in your 
head—or even on a bit of paper—you've got next to you at your 
planning poker sessions. 

Think about the jobs that will be needed to be done to build that 
piece of software. Imagine you are doing those jobs, figure out 
how long you would take to do each one, and then add them all 
up to give you an estimate for that user story. 

How much of this process should my customer 
actually see? 

Your customer should only see and hear your questions, 
and then of course your user stories as they develop. In particular, 
your customer is not involved in the planning poker game. 
Customers will want lower-than-reasonable estimates, and can 
pressure you and your team to get overly aggressive. 

When there is a question about what a piece of the software is 
supposed to do in a given situation, or when an assumption is 
found, then involving the customer is absolutely critical. When 
you find a technical assumption being made by your team that 
you can clarify without the customer, then you don’t have to go 
back and bother them with details they probably won’t understand 
anyway. 

But when you’re playing planning poker, you are coming up with 
estimates of how long you believe that your team will take to 
develop and deliver the software. So it’s your neck on the line, 
and yot/r promise. So the customer shouldn't be coming up with 
those for you. 
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A bunch of techniques for working with requirements, in full 
costume, are playing a party game, “Who am I?” They’ll give you 
a clue and then you try to guess who they are based on what 
they say. Assume they always tell the truth about themselves. Fill 
in the blanks next to each statement with the name (or names) 
of each attendee that the statement is true for. Attendees may be 
used in more than one answer 

Tonight’s attendees: 

Blueskying - Role playing - Observation 
User story - Estimate - Planning poker 


I ' 


You can dress me up as a use case for a 
formal occasion. 

The more of me there are, the clearer 
things become. 


I help you capture EVERYTHING. 


I help you get more from the customer. 


In court, I’d be admissible as firsthand 
evidence. 


Some people say I’m arrogant, but really I’m 
just about confidence. 

Everyone’s involved when it comes to me. 


► Answers on pa^e 62 . 
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develop your estimates cyclically 


The requirement to estimate iteration cycle 

We’ve now added some new steps in our iterative approach to requirements 
development. Let’s look at how estimation fits into our process... 



Blue sky Brainstorming 


o Constructing User Stories 



how \rcady -to 
CS-tir^a-tc how lohj 

"the p<rojcd-t as a 
wholc is 3 — 匕 iakc. 


^Estimate! 


O Estimate how long all of the 

customer’s requirements will take 



Get any missing information 
from the customer，and break up 
large user stories 
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gathering requirements 


Finding holes in clarity 
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sum your estimates to find out your total project duration 


A bunch of techniques for working with requirements, in full 
costume, are playing a party game, “Who am I?” They’ll give you 
a clue and then you try to guess who they are based on what 
they say. Assume they always tell the truth about themselves. Fill 
in the blanks next to each statement with the name (or names) 
of each attendee that the statement is true for. Attendees may be 
used in more than one answer 

Tonight’s attendees: 

Blueskying - Role playing - Observation 
User story - Estimate - Planning poker 



I? 

Sol ^io ns 


You can dress me up as a use case for a 
formal occasion. 


User S-tory 


The more of me there are, the clearer 
things become. 

I help you capture EVERYTHING. . 杉 . 卜 ㈣ 丫 : 1 ” 少 .. 巧卞卞七 : 10 ” 


User 


I help you get more from the customer. 


Ro|c Obscv-vatioh 


In court, I’d be admissible as firsthand 
evidence. 


Obscrvaiioh 


Some people say I'm arrogant, but really I'm 
just about confidence. 


Es 七 ima 七 e 


Everyone’s involved when it comes to me. 





Did you say plahhi^ 
pokcv? Cus-tomcv-s 
hvolvcd ih that activity. 
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gathering requirements 


Finally, youYc ready to estimate the whole project. 

You’ve got short, focused user stories, and you’ve played planning 
poker on each story. You’ve dealt with all the assumptions that you and 
your team were making in your estimates, and now you have a set of 
estimates that you all believe in. It’s time to get back to the customer 
with your total project estimate... 






u 


Add an estimate to each user story for how long you think it 
will take to develop that functionality. 


Add up all the estimates to get a total estimate for how 
long your project will take to deliver the required software. 


Awd the total project estimate is... 



Wow you get d 

"total 


Add up the each of the converged estimates for your 
user stories, and you will find the total duration for your 
project, if you were to develop everything the customer 
wants. 




Sum ol user story estimates 


489 days! 


k 
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when your project is too long 


489 days for the project? 
That s almost two years!!! 



No kidding! That’s way too long, 
By the time youve developed the 
software, my competition will 
have beaten us into the ground! 


What do you do when your estimates 
are WAY too long? 

You’ve finally got an estimate you believe in, and 
that takes into account all the requirements that the 
customer wants. But you’ve ended up with a monster 
project that is just going to take too long. 

Is it time to go back to the drawing board? Do you 
admit defeat and hand the work over to someone 
else? Or do you just ask the customer how long he 
thinks would work, forgetting about all your hard 
work to come up with you estimates in the first place? 

You’ll have to solve a crossword puzzle and work 
your way to Chapter 3 to find out how to get Orion’s 
Orbits back on track. 


11 
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gathering requirements 



Re<juireinents and Estimation Cross 

Let’s put what you’ve learned to use and stretch out your left brain a bit. 
All of the words below are somewhere in this chapter ： Good luck! 



Across 

2. When you and the customer are really letting your ideas run 

wild you are. 

3. When coming up with estimates, you are trying to get rid of as 

many.as possible. 

4. None of this language is allowed in a user story. 

7. If a requirement is the what, an estimate is the. 

9. Requirements are oriented towards the. 

12. The best way to get honest estimates and highlight 
assumptions. 

14. A User Story is made up of a .and a description. 

15.is a great way of getting first hand evidence of exactly 

how your customer works at the moment. 

18. The goal of estimation is . 


Down 

I. When you just have no idea how to estimate a user story, use 
a card with this on it. 

5. User stories are written from the perspective of the. 

6. When you and the customer act out a particular user story, 

you are . 

8. When everyone agrees on an estimate, it is called a. 

10. An estimate is good when eveyone on your team is 
feeling. 

II. The maximum number of days that a good estimate should 
be for one user story. 

13. A great user story is about .lines long. 

16. After a round of planning poker, you plot all of the estimates 

on a. 

17. You can use the .rule for breaking up large user 

stories. 
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you/* so 疗 ware development toolbox 



Tools for your Software Pevelopment Toolbox 

Software Development is all about developing and 
delivering the software that the customer actually 
wants. In this chapter, you learned about several 
techniques to help you get inside the customer’s head 
and capture the requirements that represent what they 
really want... For a complete list of tools in the book, 
see Appendix ii. 


Blwcsic/, Obsev-va-bio^ a«d Role 卢 ay 
Uscv 

pbvmi 吒 一 ev “ estwat«ov> 


pevelopmehi P〆— pU 


Si 趨 








BULLET POINTS - 

■ Blueskying gets your 
customer to think big 
when coming up with their 
requirements. 

■ A user story captures 
one interaction with the 
software from the customer’s 
perspective. 

■ User stories should be 
short, around three 
sentences in length. 

■ A short user story is an 

estimatable user story. 

■ A user story should not take 
one developer more than 15 
days to deliver. 

■ Iteratively develop your 
requirements with your 
customer to keep them in 
the loop at every step of the 
process. 
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gathering requirements 



Re<juireinents and Estimation Cross 
Solution 



you are here ► 


67 

























































































































3 project planning 



Planning for success ^ 



Really darling, my software 
development is so well planned ril 
be home on time every day for us 
to watch NASCAR together! 


Every great piece of software starts with a great plan. 

In this chapter you’re going to learn how to create that plan. You’re going to learn how to 
work with the customer to prioritize their requirements. You’ll define iterations that you 
and your team can then work toward. Finally you’ll create an achievable development 
plan that you and your team can confidently execute and monitor. By the time you’re 
done, you’ll know exactly how to get from requirements to your first deliverable. 


this is a new chapter 
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deliver what you can, when it’s needed 


Customers want their software NOW! 

Customers want their software when they need it, and not a moment later. You’ve 
come to grips with the customer’s ideas using brainstorming, you’ve got a set of user 
stories that describe everything the customer might need the software to do, and 
you’ve even added an estimate to each user story that helped you figure out how long 
it will take to deliver everything the customer wants. The problem is, developing 
everything the customer said they needed will take too long... 


Our Estimate What the customer wants 


days °{0 days| 

The *to*tal uf all the 

cs*tii^a*tcs -fov youv usev* s*to\rics 
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Orion’s Orbits still wants to modernize their booking system; they just can’t wait almost 
two years for the software to get finished. Take the following snippets from the Orion’s 
Orbits user stories, along with their estimates, and circle the ones you think you should 
develop to come up with a chunk of work that will take no longer than 90 days. 


Title: 


Pay. withYisa/MC/PaYPal 

Estimate: ... J. 1 ?. .dciys 


fitle: 


Estimate; 


Review flight 

.. . .13. 4^. 


Title: Order iw：flight iweals 

Estimate: ... H .dsys 


■ itle: 

Istinriate: 


i.i . 鄉 . 


Title 


^9.way (h spaceport 

Estimate： /? days transport 


Choose scatiwQ. 


Title: Space Miles Accpuht Hrstie ： 

Estimate: ... j. 士 . .doiy?. ^BEstimate: .. - f 


Title: 


.Appfy f or J request 

Estimate:... •/ • 午 岭 ^strowaur card 


Title: T^ke pet rjeseryatfph 

Estimate: •… 1.2：. (Jays 


Title: Manage special offers 

Estimate:.. dsy^ 


Total Estimate: 

Problems? 





f cc 3h y P^oblc^s wi-th 

广 s app^h? WY\it 

七 herb doy/h 



Assumptions? 


I |v(o*tc dovm 

.(i\\\rk you avc 
(V\CVC- 
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priorities come from your customer 


Orion’s Orbits still wants to modernize their booking system; they just can’t wait for a year and 
a half for the software to turn up. Your job was to take the snippets on page 71 and keep the 
ones you think you should develop. Here are the stories we kept: 


These a\rc 
usev- s*bo\rics - 
y/C picked- 


Title: 


?opk a shuttle 

Estimate :.. 」 弓 


Title: Pay. withYisa/MC/PayPal 

Estimate: _(iciys 


These souhded 

T 仏 K the 




Tit 


Tit,e: ?PpkScgway.m spaceport 

Estimate ： . /?. days trawsport 


% thouglvt 
."this usev* s^tov^y 
souhded Coo\l 


Estimate: … H . 如'/冬 . 


，e： 


Wlc tould 

usev stovy m *to *f «ll 


oui 


Title: View Space Miles Accpowt 

Estimate:_.d^.y?. 


TK'is is V^OY/ lo 吒 *tWmy 

-took added 

all 七 he estimates. 


Mawagc spec^^^| 

Estimate:.. I 孓 


Total Estimate: 


0 午 


VVc sV^oy/cd *tV^c 

s*tov-'»cs v/c C-Kosc *to 

七 he tus*tow»cv-. - 


But thafs not what I 
wanted at all! 


O 




I 




The customer sets the priorities 

Seems like the GEO of Orion’s Orbits is not 
happy, and can you blame him? After all that 
hard work to figure out what he needs, we’ve 
ignored him completely when deciding which 
user stories take priority for the project. 

When user stories are being prioritized, you 
need to stay customer-focused. Only the 
customer knows what is really needed. So when 
it comes to deciding what’s in and what’s 
out, you might be able to provide some expert 
help, but ultimately it’s a choice that the 
customer has to make. 
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project planning 


Prioritize wjth the customer 

It’s your customer’s call as to what user stories take priority. To help the 
customer make that decision, shuffle and lay out all your user story cards on 
the table. Ask your customer to order the user stories by priority (the story 
most important to them first) and then to select the set of features that need 
to be delivered in Milestone 1.0 of their software. 


scr will bcabUto. 

™ al 
?rs.wj.l).be.ab!eto.. 
)okmgs fciy credit 


Description: .. A Msc.r.wjJ). be able to 

leave a review for a shuttle flight 
.they, hayc bee w ow. 


Est: 


days 


Title . 0rdcrm ： fli9M.m^ls 

A uscrwillbe able to... 

w 州 . 


Description: ..A USCIf 

choose aisle or vyih 

Est ： /. 2 - (idys 

Title: ?.QP.K 珥•琴 I 

Description: .. A. P •琴 

to book a shuttle s 
data and time of 11 



What is "Milestone 1.0"? 

Milestone 1.0 is your first major release of the software to the customer. Unlike 
smaller iterations where you’ll show the customer your software for feedback, this 
will be the first time you actually deliver your software (and expect to get paid for 
the delivery). Some Do’s and Don’ts when planning Milestone 1.0: 


ou ^ ^ 7 ouV " uscv " 

av\d ask i\\t -to 

or&cr 払 cm b7 ^'<0^7 


s*tov-'»cs 


Do 


Don't. 




Don't. 




balance functionality with customer impatience 

Help the customer to understand what can be done in the time 
available. Any user stories that don’t make it into Milestone 1.0 are not 
ignored, just postponed until Milestone 2, or 3 … 

get caught planning nice-to-haves 

Milestone 1.0 is about delivering what’s needed, and that means a set 
of functionality that meets the most important needs of the customer. 

worry about length (yet) 

At this point you’re just asking your customer which are the most important 
user stories. Don’t get caught up on how long those user stories will 
take to develop. You’re just trying to understand the customer’s priorities. 


weW hot 
<9^o\rihg 

Wll 

H 3*vt back 

"to this. 
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building Milestone 1.0 


Wc know whafs iw Milestone 1.0 (well maybe) 

From all of the user stories developed from the customer’s ideas, organized into prority 
order, the customer then selects the user stories that they would like to be a part of 
Milestone 1.0 of the software... 



Sawity-check your Milestone 1.0 estimate 

Now that you know what features the customer wants in Milestone 1.0, 
it’s time to find out if you now have a reasonable length of project if you 
develop and deliver all of those most important features... 


Jfov M'»\csW 


stoics 



Actct togfetker all 
oi tke user story 
estimates lor 
Milestone 1.0 


Estimate (or 
Milcs-fcohc \ 0 


2HZ days 



pocs souy\d v-caso^ablc? 
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project planning 


If the features dow't fit, rgprioritize 

You’ve got 273 days of work for Milestone 1.0, and Orion’s Orbits want delivery in 90 days. 
Don’t worry, this is pretty common. Customers usually want more than you can deliver, and it’s 
your job to go back to them and reprioritize until you come up with a workable feature set. 

To reprioritize your user stories for Milestone 1.0 with the customer... 


o 


❺ 




❺ 


Cut out more FUNCTIONALITY 

The very first thing you can look at doing to shorten the time to delivering Milestone 1.0 is to cut out 
some functionality by removing user stories that are not absolutely crucial to the software working. 

Aoy! 

Ship a milestone build as early as possible 

Aim to deliver a significant milestone build of your software as early as possible. This keeps your 
development momentum up by allowing you and your team to focus on a deadline that’s not too far off. 

Vov\i \ti dus-tomev-s -talk 
you *m*to development 

Focus on the BASELINE functionality 乎 1 〒 从 ' ^ 

tom-Portablc witme sooner 

youv- deddl'mC) *tV)C mov-c 

-fodusedi you air\di youv- -team 


Milestone 1.0 is all about deliveringjiisf the functionality that is needed for a 
working version of the software. Any features beyond that can be scheduled for later 
milestones. 


What’s the difference between a 
milestone and a version? 

Not much. In fact you could call your 
first milestone “Version 1” if you like. The 
big difference between a milestone and a 
version is that a milestone marks a point at 
which you deliver signficant software and get 
paid by your customer, whereas a version 
is more of a simple descriptive term that is 
used to identify a particular release of your 
software. 

The difference is really quite subtle, but the 
simple way to understand it is that “Version” 
is a label and doesn’t mean anything more, 
whereas “Milestone” means you deliver 
signficant functionality and you get paid. It 
could be that Version 1.0 coincides with 
Milestone 1.0, but equally Milestone 1.0 
could be Version 0.1,0.2 or any other label 
you pick. 


thereicire no o 

- Dumb Qjuesti9ns 

C^: So what exactly is my software’s 
baseline functionality? 

A- 

厂 V The baseline functionality of your 
software is the smallest set of features that 
it needs to have in order for it to be at all 
useful to your customer and their users. 

Think about a word processing application. 
Its core functionality is to let you load, edit, 
and save text to a file. Anything else is 
beyond core functionality, no matter how 
useful those features are. Without the ability 
to load, edit, and save a document with text 
in it, a word processor simply is not useful. 

That’s the rule of thumb: If you can get 
by without a feature, then it isn’t really 
baseline functionality, and it’s probably a 
good candidate for pushing out to a later 
milestone than Milestone 1.0 if you don’t 
have time to get everything done. 


CBy\ be ov\ i*t- 


vJ I I’ve done the math and no matter 
how I cut the user stories up, I just can’t 
deliver what my customer wants when 
they want me to. What can I do? 


A 


It’s time to confess, unfortunately. If 
you really can’t build the software that is 
required in the time that it’s needed by, and 
your customer simply won’t budge when it 
comes to removing some user stories from 
the mix, then you might need to walk away 
from the project and know that at least you 
were honest with the customer. 

Another option is to try to beef up your team 
with new people to try and get more work 
done quicker. However, adding new people 
to the team will up the costs considerably, 
and won’t necessarily get you all the 
advantages that you’d think it might. 
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factoring in team performance 


Hello?! CaiVt we just add some more people to cut down 
our estimates? Add two developers, and well get done 

in 1/3 the time, right? 


O 



l*f _ 七 you 2H1> ddys, 2 - rwolrc 
people like you, that would iredude -the 
overall dcvcloprwc^-t *tinr»c by 3 -fad-fcov- 
o( Z, \rijh-t? 


It’s about more than just development time 

While adding more people can look really attractive at first, it’s really not 
as simple as “double the people, halve the estimate.” 

Every new team member needs to get up to speed on the project; 
they need to understand the software, the technical decisions ， 
and how everything fits together, and while they’re doing that they 
can’t be 100% productive. 

Then you need to get that new person set up with the right tools and 
equipment to work with the team. This could mean buying new licenses 
and purchasing new equipment, but even if it just means downloading 
some free or open source software, it all takes time and that time 
needs to be factored in as you reassess your estimates. 

Finally, every person you add to your team makes the job of keeping 
everyone focused and knowing what they are doing harder. Keeping 
everyone moving in the same direction and on the same page can 
become a full-time job, and as your team gets larger you will find that 
this complex communication can start to hit your team’s overall ability to 
be productive and develop great software. 


In fact, there is a maximum number of people that your team can 
contain and still be productive, but it will depend very much on your 
project, your team, and who you’re adding. The best approach is to 
monitor your team, and if you start to see your team actually get less 
productive^ even though you have more people, then it’s time to 
re-evaluate the amount of work you have to do or the amount of time in 
which you have to do it. 

\ Ulcir Oh ih iWis dhaplcir you II be ihlv-odudcd 

bu\rh-doy/h \raic g\raph. This is a yrcai 
y° o1 ^ the e o*f yo 砍 

to. 
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More people sometimes means dimmishing returns 


Adding more people to your team doesn’t always work as you’d expect. If 1 person 
takes 273 days to complete Milestone 1.0, then 3 people won’t necessarily take 91. In g 

fact they could actually take much longer! Take a look...performance doesn’t always 3dd°^ ^ polhf 

increase with the size of your team: A ^ ，h 9 peop/ c ’ 


About Kcv-c, youv- 
s*t3\rts bo out 











⑽ V ) •管 




… om V"3"tc o-p 
dcvclopr^ch-t wov~k 
dually bcihj dohc 


h n； a 泌 。' 
咖 〆 “ as \^ 
d\css 、十⑺ 



ZO+ 


丄 V d 啊 1c 

OY\ 


people 


or 

tWeiare no o 

Dumb Questi9ns 


Is there a maximum team size that I should 
never go over? 

Not really. Depending on your experience you 
may find that you can happily handle a 20-person team, 
but that things become impossible when you hit 21. 
Alternatively you might find that any more than three 
developers, and you start to see a dip in productivity. The 
best approach is to monitor performance closely and 
make amendments based on your observations. 



Do you think the size of your project affects 
this graph? What about if you broke your 
project up into smaller sub-projects? 
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building achievable milestones 


Work your way to a reasonable Milestone 1.0 

With Orion’s Orbits, going from one person to three — by adding two 
more developers — can have a positive impact. So let’s see how that 
works out: 

First you add two new people to your team... 

Adding two developers to your team (that’s three including you) helps, but it’s not a magical 
solution. Two developers can add a lot of work time to your project, but there’s still work left: 



\°{0 days ] - ^ days 


Days d wovk that youv 

of Z, thieve 
ih days. 


of y/o\rk id 七 

dof 


...then you reprioritize with the customer 


Now you’ve got a nice way to figure out what has to be removed. We’ve got 190 days of work 
time, and 273 days of work. So we need to talk to the customer and remove around 83 days 
of work by shifting out some user stories from Milestone 1.0. 



l/t> days o- 
y/o\rk *to do 





Cus-torv\C\r removed -features 


tWeiare no o 

Dumb Qu©sti9ns 


days 

Looking better with 3 -Pew days 
Ic-rt ovc\r "to give you a bit o( 

spol^e ih you\r milcs-fcohc- 


But 184 days of work is less than the 190 days that our 
three-developer team can produce, shouldn’t we add some 
more features with the customer? 

The overall estimate doesn’t actually have to be exactly 190 
days. Given that we’re dealing with estimates anyway, which are 
rarely 100% accurate, and that we tend to be slightly optimistic in 
our estimates, 184 days is close enough to the 190-day mark to be 
reasonably confident of delivering in that time. 


How did you come up with 190 days when you added 
two new developers? 

At this point this number is a guesstimate. We’ve guessed 
that adding two people to build a team of three will mean we can 
do around 190 days of work in 90 calendar days. There are ways 
to back up this guess with some evidence using something called 
“team velocity," but we'll get back to that later on in this chapter. 
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BE th^ 0 _衡 





丁 hihk about bdselihe 
-fuhd-tiohali-ty. I-P a 4atuv-c \s^i 
csschtial, it s probably hot a 10 . 


Now it’s your chance to he the customer. You need to build 
a plan for A^ien you are going to develop each of the user 
Stories for Milestone 1.0, and to do that you need to asl^ 
the customer A^iat features are most important so that you 
can develop those first. Your job is to play the customer 
by assigning a priority to the Milestone 1.0 user stories. 
For each user story, assign it a ranking in the square 
provided, depending on Kow important you tiling that 
feature is using the Key at the bottom of the pa^e. 


Title ： . . .PaY.usmg .. 
.."Space Miles" 

Est ： ..(? days. 


Title: 


Est: 


Order Iw-flightweals 

.13. days.. 


Priority: 


Priority: 


I 




Review fliaht 


- itle . Manage special 
offers 


E st: . .13. d^ys 

Priority: 


!Est: • .1.3. days. 





Priority: 



Title: ... 

MC/payPa| 

□ 


Title: . . . 解 " 如邱 ® Mil— 

account 


Est: 


Priority: 


Est: . _l • 午 . day? 


Priority: 


Priorities Key 


Most Important 


Title: 


Choose scatijig. 


Est ： ..lUay 

Priority: 


Title: 


View shuttle deals 


Est: ..( 2 r.da.ys. 

Priority: j j 


Tm e: Vpg.iw.tp "Fr ? 叩州 t.. 

Asirowaut" account 


Est ： . .1.9. days. 


Priority: 


Title: 


Est; 


Pook a shuttle 


./?. days. 

Priority: j" | 


Title: 


View flight 
reviews 

Est: J.Z.d$ys. 

□ 


Priority: 


Title:. Apply .fpr."fr?Quewt 

astrowaut" card 
Est: _ •/ • 午 . day?. 


Priority: 


一。 V" usev- sior-y, 

wha-t pv^iov-i-ty ii 
•s ih the box provided. 
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your customer decides priority 



&E . Cu % 腑 

Your job was to play the customer and prioritize the 
Milestone l.o user stories. Here are the priorities 
that we assigned to each of the user stories. 

Me also laid out the user stories in order of 
priority … 

0}rd ^ ^ ^osiio least 

'^pov-ta^^ -to -the ^us-tomev- 



tliereiare no ^ 

Dumb Qu©sti9ns 


Q/ Why are the priorities 10, 20,30, 
40, and 50? 

Powers of ten get the brain thinking 
about groupings of features, instead 
of ordering each and every feature 
separately with numbers like 8 or 26 or 
42. You’re trying to get the customer to 
decide what is most important, but not 
get too hung up on the exact numbers 
themselves. Also, powers of ten allow 
you to occasionally specify, say, a 25 
for a particular feature when you add 
something in later, and need to squeeze 
it between existing features. 

If it’s a 50, then maybe we can 
leave it out, right? 

No, 50 doesn’t mean that a user 
story is a candidate for leaving out. At 
this point, we’re working on the user 
stories for Milestone 1.0, and so these 
user stories have already been filtered 
down to the customer’s most important 
features. The goal here is to prioritize, 
not figure out if any of these features 
aren’t important. So a 50 just says it can 
come later, not that it’s not important to 
the customer 

What if I have some non- 
Milestone 1.0 user story cards? 

: Assign a priority of 60 to those 
(cards for now, so they don’t get mixed in 
|with your Milestone 1.0 features. 

And the customer does all this 

Iwork? 

You can help out and advise, 
maybe mentioning dependencies 
between some of the user stories. But 
the final decision on priorities is always 
the customer's to make. 


80 Chapter 3 


































































































































project planning 





pMrst ohc added 

-Pov- you 

if 


Now that you have your user stories for Milestone 1.0 in priority order, it’s time to 
build some iterations. Lay out the user stories so they make iterations that make 
sense to you. Be sure and write down the total days of work, and how long that 
will take for your team of three developers. 



Total Days ： | ! Divide by 1 > developers ： ! 







Total Days ： ! ! Divide by 1 > developers ： j 


1> 




<YACS*t\0V\ 


r _ ■ ■ — _ t 

Total Days ： ; ; Divide by 1 > developers：[ 


^ What do you think you should do at the 
end of an iteration? 


• 寸 oo 杳 J uo ▲ 
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milestone = paid, iteration = on track 


Fireside Chats 



Tonight’s talk ： A sit-down discussion between an iteration 
and a milestone. 


Milestone: 


Iteration: 


Hello there, iteration, seems like it’s only been a 
month since I saw you last. 


Almost exactly a month. And you’ll see me again 
next month, I can guarantee it. About three times, 
and we’re ready for you, Milestone 1.0. 


So how are things going on the project? It seems 
like you’re always showing up, and I just arrive for 
the big finish. Actually, what’s your purpose? 


Naive? Look, just because I’ve had a few customer 
run-ins before doesn’t mean I’m not important. I 
mean, without me, you wouldn’t have software at all 
,let alone get paid! Besides, just because I’ve shown 
up and surprised the occasional customer from time 
to time... 


To make sure things go great, of course. That’s my 
job really, to make sure that every step of the way 
from day 1 to day 90, the project stays on track. 
What, you thought you could just show up three 
months into the project and everything would be just 
like the customer wants it? A bit naive, aren’t you? 


Oh, I really sympathize with you there. I hate it 
when the customer isn’t happy with me. But then 
again, there’s a lot more time to fix things. I mean, 
we get together, you know, me and the customer, at 
least once a month. And, if things are bad, I just let 
the customer know it’ll be better next time. 


I used to try that, too. I’d try and soften the blow by 
explaining to the customer that all of their problems 
would be fixed in the next version of the software, 
but that wasn’t what they wanted to hear. Lots of 
yelling, and I’d slink off, ready to go back to work 
for a year or so, and see if the customer liked me 
better next time. 
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But you’re shorter than a year now, right? 


project planning 


Milestone: Iteration: 

Well, I try to be, but sometimes that’s just how long 
it takes, although I just love seeing the customer 
more often. At least once a quarter seems to line up 
with their billing cycles. And not so long that I get 
forgotten about; there’s nothing worse than that. 

Yeah, nobody forgets about me. Around every 
month, there I am, showing up, putting on a song 
and dance, pleasing the customer. Really, I can’t 
imagine how you ever got by without me. 

Are you kidding? You’re not even an alpha or a 
beta....just some code glued together, probably an 
excuse for everyone to wear jeans to work and drink 
beer on Friday afternoon. 

Oh, it’s a little more than that, don’t you think? 
Where would you be without me paving the way, 
making sure we’re on track, handling changes and 
new features, and even removing existing features 
that aren’t needed any more. 

Ha! Where would I be? Same place I am right now, 
getting ready to show the customer some real... 

...hopefully working? 

...software. Hey, wait. Hopefully? I’ve got a few 
hopes for you, you little... 

Well, you got the little part right. Why don’t you just 
shuffle off for another 30 days or so, we’ll call you 
when all the work’s done. Then we’ll see who Friday 
beers are on, OK? 

Ungrateful little punk...release this! 


Sure thing, and since I do my job, I’m sure you’ll 
work just fine. I’m outta here, plenty of work left to 
be done... 
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continuously buildable and runnable 


秦 b 

ExeRctSe 


Your job was to lay out the user stories so they make iterations that make 
sense. Here’s what we came up with... note that all our iterations are within one 
calendar month, about 20 working days (or less). 



V®u\r ahswc\rs dould be 
but make 
su 代 you v/Cht ih 
o\rdc\r p\riov»ity … 


Title 


Manage special 

offers. 

Est ： . .13. days.. 


Priority: 


Title ： .Pooka shuttle 

Est ： ../? days. 

Priority: 


Title:. .Pay yyrith Visa/ 
MC/payPa| 

Est ： ../?..d.ay s . 

0 


Priority: 


Title: 


Est: 


Priority: 


/\dtually, the a 
View Shuttle . is . !•?.? 碎卜七 

(Jg^ls v-ulc is -to \rou^d 

.). 1 . .mal 

I - 1 

I you a\rc 50 


^\ratior\ 


pa，1 



Title: 


Cbpose seatihg 



Title: 


Order |w-f light. 

meals. 

Est ： . .13. days.. 


Title: 


.^.Viw. flight 



Title: 


View f Hght.rsviews 


Est: . J.2r.ddy§. 

Priority: 



Total Days： ! *50 ! Divide by 1 > developers： ! ! 


Title: Apply f(>r"f 麵印 

astrpMaur.card 

E st: J. 午 . days. 


Tm e: Lpgjw.t.o • :F 例卿 t. 

Astrowauf accouw 


Title: Vj.^w "Space Mile 
account 


Est: 


•I . 午 . days 




Total Days： j *50 j Divide by 1 > dcvelopcv-s： | ZO ! 

What do you think you should do at the 

end of an iteration? £hov/ {ht tusWvr a^d iheir ^td\>at\c 

tJiereiare ng o 

- Dumb Qii©sti9ns - 


What if I get to the end of an iteration, and I don’t have 
anything to show my customer? 

The only way you should end up at the end of an iteration and 
not have something to show the customer is if no user stories were 
completed during the iteration. If you’ve managed to do this, then your 
project is out of control and you need to get things back on track as 
quickly as possible. 


Keep your software continuous !； 
liuilcting and your software 
always runnaLle so you can 
always get leectLack Irom tke 
customer at tke end ol an 


iteration. 
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Iterations should be short and sweet 

So far Orion’s Orbits has focussed on 30-day iterations, with 3 
iterations in a 90-day project. You can use different size iterations, 
but make sure you keep these basic principles in mind: 


Keep iterations siiort 

The shorter your iterations are, the more chances you get to 
find and deal with change and unexpected details as they 
arise. A short iteration will get you feedback earlier and bring 
changes and extra details to the surface sooner, so you can 
adjust your plans, and even change what you’re doing in the 
next iteration, before you release a faulty Milestone 1.0. 



Each iteration should be a balance between dealing with change, 
adding new features, beating out bugs, and accounting for real 
people working. If you have iterations every month, that’s not 
really 30 days of work time. People take weekends off (at least 
once in a while), and you have to account for vacation, bugs, 
and things that come up along the way. A 20-work-day iteration 
is a safe bet of work time you can handle in an actual 30-day, 
calendar-month iteration. 


SO-day itev-atiohs 
basically 1>0 
CALBHVAR days … 


… you cav\ assume 
m -to about ZO 
days J 


SHORT iterations lielp you 

deal witk ckange anct kee 
you anct your team motivatect 
anct loeusect. 
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bringing reality to your plan 



Below is a particular aspect of a user story, iteration, milestone...or 
perhaps two, or even all three! Your job is to check off the boxes for 
the different things that each aspect applies to. 

User story Itercttion 

I result in a buildable and runnable bit — — 

of software. — — 

I’m the smallest buildable piece of — — 

software. — — 


In a full year, you should deliver me a 
maximum of four times. 


I contain an estimate set by your team. 


I contain a priority set by the customer. 

When I’m done, you deliver software to 
the customer and get paid. 


I should be done and dusted in 30 days. 


Milestone 
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Comparing your plan to reality 



It looks like well be doing fine on the plan as 
long as we can all fit in a full five-day week. 


■ ^iharpen your pencil 


Bob: Oh, just so you know, Nick is coming in at 11 today, 
he’s got a doctor’s appointment... 

Laura: What? 

Bob: And while we’re talking, the IT guys are installing 
Oracle 9 on my machine this afternoon, so you might 
want to keep that in mind, too. 

Laura: Oh great, any other nasty surprises in there that I 
should be aware of? 

Bob: Well, I have got a week of vacation this month, and 
then there’s Labor Day to take into account... 

Laura: Perfect, how can we come up with a plan that 
factors all these overheads in so that when we go get 
sign off from the GEO of Orion’s Orbits we know we 
have a plan we can deliver? 




you thihk ou^ ZO- 


See if you can help Bob out. Check all the things that you need to 
account for when planning your iterations. 


Paperwork 


Equipment failure 


Holidays 


Sickness 


Software upgrades 


Frank winning the lottery 
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velocity applies your real performance 













鲁 


Below is a particular aspect of a user story, iteration, milestone...or 
perhaps two, or even all three! Your job is to check off the boxes for 
the different things that each aspect applies to. 


User 


iter^ttion 


Milestone 


I result in a buildable and runnable bit 
of software. 

I’m the smallest buildable piece of 
software. 

In a full year, you should deliver me a 
maximum of four times. 

I contain an estimate set by your team. 

I contain a priority set by the customer. 

When I’m done, you deliver software to 
the customer and get paid. 

I should be done and dusted in 30 days. 


><J IX 


A 




kA m [X 


x 




\ 


ri^harpen your pencil 


See if you can help Bob out. Check all the things that you need to 

account for when planning your iterations._ 丁 h’my like "this al 、 






so we have -to pi, 

X 

Paperwork 


Equipment failure 


Holidays 


七 hern. 


X 



Frank winning the lottery 
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Vdocity accounts for overhead m your estimates 

It’s time to add a little reality to your plan. You need to factor in all those annoying 
bits of overhead by looking at how fast you and your team actually develop software. 
And that’s where velocity comes in. Velocity is a percentage: given X number of 
days, how much of that time is productive work? 



Take days y/ork \i will take you 
•to develop a user s*bov*Y) or ar\ \icrat\oY\, 
or dr\ cntiv-c milcsWc • 


But how can I know how fast 
my team performs? We’ve only 
just gotten started! 


Start with a velocity of 0-7- 

On the first iteration with a new team it’s fair to assume 
that your team’s working time will be about 70% of 
their available time. This means your team has a velocity 
value of 0.7. In other words, for every 10 days of work 
time, about 3 of those days will be taken up by holidays, 
software installation, paperwork, phone calls, and other 
nondevelopment tasks. 

That’s a conservative estimate, and you may find that over 
time, your team’s actual velocity is higher. If that’s the case, 
then, at the end of your current iteration, you’ll adjust 
your velocity and use that new figure to determine how 
many days of work can go into the next iteration. 

Best of all, though, you can apply velocity to your amount 
of work, and get a realistic estimate of how long that 
work will actually take. 


Yc*t ar\o*tVicv- 
*to 

sVio\rt 

you adjust 


Zs 7：l ay ； °f wo ^ 

y 蚪州 〉? 1 如 tioh, holidays, cic. 


^^ days v/o\rk 二 days ve^uired b> 



vclodi-ty 


jet v/ork dov\t 


-3hd PA/fpg that humb 饮 by 丫财 


s :: S a 上 ㈣ 许 

to days >wovk '«s vcally oy^ about 


you are here ► 


89 




from ideal to real estimates 


Programmers think in UTOPIAN days... 

Ask a programmer how long it takes to get something done, like writing a PHP 
interface to a MySQL database, or maybe screen-scraping World Series scores from 
espn.com. They’re going to give you a better-than-best-case estimate. 


Here's what a programmer SAYS 



Sure, no problem, I can crank 
through that in two days. 


Mo 呼 developer assume thcyVc the ohlv 


but here's what he's really THINKING 


ril grab a Monster on the way home, program till 3 
A.M., take a Halo break, then work through the morning. 
Sleep a few hours, get the guys over to hack with me, 
and finish at midnight. As long as nothing goes wrong... 
and Mom doesn’t need me to pick up dinner. 


s m 


㈣㈣ 心 

develop k^oYiS about. 
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developers think m REAL-WORLP days... 

To be a software developer, though, you have to deal with reality. You’ve probably 
got a team of programmers, and you’ve got a customer who won’t pay you if you’re 
late. On top of that, you may even have other people depending on you — so your 
estimates are more conservative, and take into account real life: 


You s*ta\rt wi*th a bu*t take 

away weekends holidays. 



ov> atW dev 岭⑼七 . 




vclodi-ty 





I 午 ddys REAL y/ork 


This is di lot lowcv- humbev- o( 
C3iy\ be rwov-c 




Jrarpen your pencil 


lowcv* O-T days, bu 七 Vou 

COHPIVBHT \y\ this humbev-. 



Take your original estimates for each iteration from the solution on 
page 84 and apply a 70% velocity so that you can come up with a 
more confident estimate for all the work in Milestone 1.0. 


I 七 eta 七 ioh I 
*5*5 days v/ork / 0.7 

*50 days o-f y/ovk / 0.7 
("tcv-atioh 1> 

彐 S days <Jc y/o\rk / OH 
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confidence comes at a price 


Whew is your iteration too long? 


Suppose you have three developers on your team who are working at a velocity of 0.7. This 
means that to calculate how long an iteration will really take your team, you need 
to apply your velocity to the iteration’s estimate: 



七 eva 七 ioh I 

*5 days / 0.7 — 



l^tcv-atioh Z 
O days / 0.7 二 



1> 

days / 0.7 二 


1°{ days 


estimates av-c 

oh 9 cir...bu-t youVc buildihq CoJ^\dtUt 

”败 estimate a— ― ^ 



m days 

day 七 . 


91> days 





23 午 days d y/o\rk 


So if you have? developers, each of them has to work 7$ 
days m 3 months... but there are only 60 working days. 





How would you bring your estimates 
back to 20 work-day cycles so you 
can deliver Milestone 1.0 on time, 
without working weekends? 


Even with three 
people, we still can’t deliver 
Milestone 1.0 in time! 
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Peal with velocity BEFORE you break into iterations 

A lot of this pain could actually have been avoided if you’d applied velocity at the 
beginning of your project. By applying velocity up front, you can calculate how many 
days of work you and your team can produce in each iteration. Then you’ll know exactly 
what you can really deliver in Milestone 1.0. 


First, apply your team velocity to each iteration 


By taking the number of people in your team, multiplied by the number of actual working 
days in your iteration, multiplied finally by your team’s velocity, you can calculate how 
many days of actual work your team can produce in one iteration: 


% zo % 

The ⑽你 b 饮 of 10 了 days m 





V^uV" 七 card’s 七 

pass velocity. 


TiiC amou 灼七 o*f >wov-k, m 
fevso^-days, youv- -team 


Add your iterations up to get a total milestone estimate 

Now you should estimate the number of iterations you need for your milestone. Just 
multiply your days of work per iteration by the number of iterations, and you’ve got the 
number of working days you can devote to user stories for your milestone: 


午 Zx' 二 

itev-atiohs ih 
Alilcs-fcohC I.O. 


m 


'Cf y/o^k m days 
you dr^d youv- team do bc-rov-c 
M*ilcs*boy>c 10 meeds bo be shipped- 


tliereicire no o 

Dumb Questions 


That sucks! So I only have 14 days of actual productive 
work per iteration if my velocity is 0.7? 

0.7 is a conservative estimate for when you have new members 
of your team coming up to speed and other overheads. As you and 
your team complete your iterations, you'll keep coming back to that 
velocity value and updating it to reflect how productive you really are. 


With velocity, my Milestone 1.0 is now going to take 79 
working days, which means 114 calendar days. That’s much 
more than the 90-day/3-month deadline that Orion’s Orbits set, 
isn’t that too long? 

Yes! Orion’s Orbits need Milestone 1.0 in 90 calendar days, so 
by applying velocity, you’ve now got too much work to do to meet that 
deadline. You need to reassess your plan to see what you really can 
do with the time and team that you have. 
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iterations with velocity 



E%edclSe 


When your iterations contain too much work for your team, there’s nothing else to 
do but reshuffle work until your iterations are manageable. Take the Orion’s Orbits 
Milestone 1.0 user stories and organize them into iterations that each contain no 
. .(S more than 42 days of work. 

vouv team w do •… a 

2*0 - dayA-a6tov-^5 


T » le ,. View shuttle 

- 1 

Title ： Pooka shuttle 1 

I -: - 

Title ： . . . Pay with Visa/ 

I 

Title. Manage special. 

deals 

... MC/PayPal 

offers 

Est: .12r.day$. 

Est ： I? days 

Est ： /?.d.ays 


Priority: \Q 

. .. 

Priority: jQ 

二回 

[si: 厂 .- 

Priority: \Q 





V 


tusWcvs ov^mal ordtr o\ 
—— — 切”祕 




Title: 


Chooseseatihg 



Title 


Order Iw-f light 

meals. 

Est ： . .13. .days. 


Title: 


.^yiw.f.iight 


E st: . .13. days. 

Priority: 回 


Title 







/ 




\ 


/ 


\ 


/ 




V 
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PU out cadh itcv-atioh by addi^ 
us 饮 s-to\rics that tov^t out io 
a\rouhd 午 Z days o-f wov-k. 

v/ 


- ^ ~' ■— — — _ 

1 七 era 七 ioh 1 

■ — — — — _ 

Toia\ Pays of work ： i i 、 

l . _ « « » j 

/ 

—— ■— — 一 — ^ 

\ 

_ | 

- - - 

/ 一 — ■ — —■ 

1 七的七 ion Z 

Total Pays of y/o\rk : 丨 | / 

1 1 

h _■■一 _ j 

/ 

,V 

~ ~ ———_ 

~ ^ __ y 

a^v uscv sW,es 如 七 

1 \itraho^ kor 

M»lcs*tov\C 1 ^ ^ cv，c ^ 

1 七 era 七 ion 冬 

詹及 f f % f 

丨_____電 

Total Days o-f work: | | 

1 1 

~ 777"： --- 


Usev - s-fcorics 七 ha 七 v / o ^ ’七 f rt 
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reality means being honest 



E%edclSe 
SoiniiON 


Your job was to to take the Orion’s Orbits user stories and aim for 
iterations that contain no more than 42 days of work each. 



I 七饮 aii 


Total Days of work: | 午 Z I 



L « » _ _ _ ■! 


Tme ： ... Reviewfliqht 

Title- View flight reviews. 

Title ： . Apply for Space 



..Miles Loyalty Card 

Es *： . .13. days. 

Est: . 

Est: 」 午 days 1 

Priority: 

^ __ ^ 

Priority: 午 0 


I 七 era 七 io 妁 3 


Tiicsc uscv 


s-tovics dvofpcd o-f flar\. 


Total Days of work: | | 




I V - 

Title. Logiw to "Frequent. 

A I 

Tme. View "Space Miles". 

Astronaut"' account 

account . 

di^vs . 

Est: 1 午 days . ... 

Priority: 

Priority: 


Title: ... .PaY.i/sihg … 

..."Space Miles" 

Est ： ..(?. days.. 


Priority: 




User 


stories 


■ha- 


y/oh 
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Time to make an evaluation 


So what’s left? You’ve probably got a lot of user stories that still fit 
into Milestone 1.0 … and maybe a few that don’t. That’s because we 
didn’t figure out our velocity before our iteration planning. 


Estimates wi-thou-t vclo^i-ty 

act you ihio meal double with 
youir 



All v/ovk 
tBv\ kc dov\c 
M\lcs*toir\C 1-^ 



Milcs-bohC 



TV^c usev 如士 s 
如 m 1.0 


Peliver the bad news to the customer 


It’s the time that every software developer dreads. You’ve 
planned out your iterations, factored in the velocity of your 
team, but you still can’t get everything your customer wants 
done in time for their deadline. There’s nothing else to do 
but come clean... 


That sucks! So you can do 
everything except the online 
''Space Miles” features. 
Hmm...Let me think about it.., 


O 



Thc\rcs ho 
tv-idk hc\rc...you 
have io tdl the 
^us-tomcv- ^hd see 


山七 they waht 

■fco do. 
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breaking realistic but bad news 



Wote -flrom hurrah \rCSou\rdcs ： wc ike 

七心 Uhsyr^athetid ^sio^sJ 


Managing customers 


Customers usually aren’t happy when you tell them you can’t get everything done 

in the time they want. Be honest, though; you want to come up with a plan for 

Milestone 1.0 that you can achieve, not a plan that just says what the customer 

wants it to say. --- …扣 d has you oy\ d -fast brack *to 

So what do you do when this happens? 

It’s almost inevitable that you’re not going to be able to do everything, so it helps to be 
prepared with some options when you have to tell the customer the bad news... 



Add an iteration to Milestone 1.0 

Explain that the extra work can be done if an additional iteration is added to the plan. That 
means a longer development schedule, but the customer will get what they want in Milestone 1.0. 


午 z 


% 




-team 






Explain that the overflow work is not lost，just postponed 

Sometimes it helps to point out that the user stories that can’t make it into Milestone 1.0 are not 
lost; they are just put on the back burner until the next milestone. 




Milcs-fconc 


TV^csc stoics avW 七 
•brasV^cd - 七 ㈣ just d 山 
M\lcsto^ t O. ht m.lcs 

so \wfov-tay\*t ^ 

讀妊 ovcv W 办 a 

dcvclofwcy>*t *tcaw? 



Be transparent about how you came up with your figures 

It sounds strange, but your customer only has your word that you can’t deliver everything 
they want within the deadline they’ve given you, so it sometimes helps to explain where you’re 
coming from. If you can, show them the calculations that back up your velocity and how this 
equates to their needs. And tell your customer you want to deliver them successful software, 
and that’s why you’ve had to sacrifice some features to give yourself a plan that you are 
confident that you can deliver on. 
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thereiare no o 

Dumb Questi9ns 


If l，m close on my estimates, can I fudge a little and 
squeeze something in? 

We REALLY wouldn’t recommend this. Remember, your 
estimates are only educated guesses at this point, and they are 
actually more likely to take slightly longer than originally thought than 
shorter. 

It’s a much better idea to leave some breathing room around your 
estimates to really be confident that you’ve planned a successful set 
of iterations. 

I have a few days left over in my Milestone 1.0. Can’t I add 
in a user story that breaks my day limit just a little bit? 

Again, probably not a good idea. If your stories add up to leave 
you one or two days at the end of the iteration, that’s OK. (In Chapter 
9 we'll talk about what you can do to round those out.) 


0.7 seems to add up to a LOT of lost time. What sorts of 
activities could take up that sort of time? 

0.7 is a safe first guess at a team’s velocity. One example is 
where you are installing a new piece of software, like an IDE ora 
database (naming no specific manufacturers here, of course). In 
cases like these two hours of interrupted work can actually mean 
FOUR hours of lost time when you factor in how long it can take a 
developer to get back in “the zone” and developing productively. 

It’s also worth bearing in mind that velocity is recalculated at the 
end of every iteration. So even if 0.7 seems low for your team right 
now, you’ll be able to correct as soon as you have some hard data. 
In Chapter 9 we’ll be refining your velocity based on your team’s 
performance during Iteration 1. 


OK, without squeezing my last user story in I end up 
coming under my work-day limit by a LONG way. I have 15 days 
free at the end of Milestone 1.0! Is there anything I can do about 


that? 

To fit a story into that space, try and come up with two simpler 
stories and fit one of those into Milestone 1.0 instead. 


Alright, ifs worth it to me to 
lose space miles in Milestone 
1.0 to keep things moving. 
Let's do it. 


Stay coniident tkat you can ackieve 
tke work you sig[n up lor. You skoulct 
promise and Jeliver ratker tkan 
overpromise and faiL 



you are here ► 


99 












introducing the big board 


The Pig Poard ow your wall 

Once you know exactly what you’re building, it’s time to set up your software development 
dashboard for Iteration 1 of development. Your dashboard is actually just a big board on the wall 
of your office that you can use to keep tabs on what work is in the pipeline, what’s in progress, 
and what’s done. 


Uscv s-fcovics -Pov 

ltcv*a-tioh / 
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User s-borics 
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project planning 



Usually you\r projed： boa\rd is a whiteboavd, so you w 
use it ahd a^aih between itevatiohs ay\d pv-oje^ts. 


麵 




3u\rh Doy/y\ 



A^y usc\f sio\ries -Pov- this 
i"tc\r3*tioh "that woh^t -Pit Oh the 
Ic-Pt 3\rc put hcv-c. 


I Completed 


“ io 如 Aat s dov>c. 


USCV 

setter -to 
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happiness is a project that can be achieved 





Wov-k -for 


You may have noticed a graph at the top right of your development dashboard, but what is it 
for? Take a few minutes to glance over the burn-down graph below and write on it what you 
think the different parts of the graph are for and how it is one of the key tools for monitoring 
your software development progress and ensuring that you deliver on time. 


you ov* youv* 
y/V^olc 七 O? 


Burh Doy/h 



- ► Aiders on page 104. 

What do you think would be measured on 
this graph, and how? 
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project planning 


How to rm your team's lives 

It’s easy to look at those long schedules, growing estimates, and 
diminishing iteration cycles, and start to think, “My team can 
work longer weeks!” If you got your team to agree to that, then 
you’re probably setting yourself up for some trouble down the line. 


Personal lives matter 

Long hours are eventually going to affect your personal 
life and the personal lives of the developers on your team. 
That might seem trite, but a happier team is a more 
productive team. 


Fatigue allects productivity 


Tired developers aren’t productive. Lots of studies suggest 
that developers are really only incredibly productive for 
about three hours a day. The rest of the day isn’t a loss, 
but the more tired your developers are, the less likely 
they’ll even get to that three hours of really productive 


time. 


Be conlictent 
in your plans 

V applying 
velocity 
anct not 
overworking 
yoursell and 
your teanu 


^^BUILET POINTS - 

■ The first step to planning what you are going to develop 
is to ask the customer to prioritize their requirements. 

■ Milestone 1.0 should be delivered as early as you can. 

■ During Milestone 1.0 try to iterate around once a 
month to keep your development work on track. 

■ When you don’t have enough time to build everything, 

ask the customer to reprioritize. 


■ Plan your iterations by factoring in your team’s velocity 
from the start. 

■ If you really can’t do what’s needed in the time allowed, 
be honest and explain why to the customer. 

■ Once you have an agreed-upon and achievable set of 
user stories for Milestone 1.0, it’s time to set up your 
development dashboard and get developing! 
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performance and bum down 



You were asked to take a few minutes to glance over the burn-down graph below and describe 
what you think the different parts of the graph are for and how it is one of the key tools for 
monitoring your software development progress and ensuring that you deliver on time. 


Burn Dovm 



be measured on this 


graph, and how? 

This. _3 疒 研 h..^ 9 hiip\rs hoy/.you. . 
your arc you\r v/o\rk, 

measured m days oy\ ihc vcriidal a^is. 
This 'thch ylo*ts how ^uidkly you 
七 idk o++ you\r y/o\rk \rcma*mih^ d^dihs^b "the 
humbev- o+ ddys \y\ youv i*bc\r3*tioh. 


o 


We’ll talk a lot more about burn- 
down in the next few chapters. 

Don’t worry if you’re still a little fuzzy 
on how burn-down rates work, and how 
to track it. You’ll start creating a chart of your own in the 
next chapter, tracking your project’s progress. 
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project planning 



Software Developirient Planning Cross 

Let’s put what you’ve learned to use and stretch out your left brain a bit! 
All of the words below are somewhere in this chapter ： Good luck! 



11 


Across 

3. At the end of an iteration you should get.from the 

customer. 

5. Velocity does not account for.events. 

6. Ideally you apply velocity.you break your Version 1.0 

into iterations. 

11. You should have one.per calendar month. 

13. Every 3 iterations you should have a complete and running 

and releasable.of your software. 

14. Velocity is a measuer of your .'s work rate. 

15. 0.7 is your first pass.for a new team. 

16. At the end of an iteration your software should be. 

17. When priotitizing, the highest priority (the most important to 

the customer) is set to a value of. 

18. Any more than.people in a team and you run the risk 

of slowing your team down. 


Down 

1 _ Your customer can remove some less important user stories 
when.them. 

2. Every 90 days you should.a complete version of your 

software. 

4. The.sets the priority of each user stor. 

7. The rate that you complete user stories across your entire 
project. 

8. You should always try be.with the customer. 

9. The set of features that must be present to have any working 

software at all is called the.functionality. 

10. At the end of an iteration your software should be. 

12. You should assume.working days in a calendar 

month. 
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you/* so 疗 ware development toolbox 



Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter, 
you added several new techniques to your 
toolbox... For a complete list of tools in the book, 
see Appendix ii. 


pgveloyw ⑼七 

ta\t^ days rbera 七咖 

ii &士峰 }转聲 

^oosnr>5 4a 七 rberaW Y 

y/ill be buil-t rn- 


Dcvcl 


Opm 


Chi PHhdples 


〜 i Wio,s shci a,d 

㈣ 此 tfe ^t：L 

P^ise, ^hd deliver 


^AYS be ho^si wiih ihe 


^us-torh 


C\r 


^^^BUUET POINTS - 

■ Your customer prioritizes 

what is in and what is out for 
Milestone 1.0. 


■ Build short iterations of 
about 1 calendar month, 20 
calendar days of work. 

■ Throughout an iteration 
your software should be 

buildable and runnable. 


■ Apply your team’s velocity to 
your estimates to figure out 
exactly how much work you 
can realistically manage in 
your first iteration. 

■ Keep your customers 
happy by coming up with a 
Milestone 1.0 that you can 
achieve so that you can be 
confident of delivering and 
getting paid. Then if you 
deliver more, they’ll be even 
happier. 
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Software Development Planning Cross 

Solution 
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4 user stories and 伽 ks 



Getting to the real work 


I m sure that eighth layer of wax is 
important, but couldn’t we get going? 
We should already be there... 








V 4 i 


I 


It’S time to go to work. User stories capture what you need to develop, but now 
it’s time to knuckle down and dish out the work that needs to be done so that you 
can bring those user stories to life. In this chapter you’ll learn how to break your user 
stories into tasks, and how task estimates help you track your project from inception 
to completion. You’ll learn how to update your board, moving tasks from in progress to 
complete, to finally completing an entire user story. Along the way, you’ll handle and 
prioritize the inevitable unexpected work your customer will add to your plate. 


this is a new chapter 
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introducing iSwoon 


Introducmg (Swoon 


Welcome to iSwoon, soon to be the world’s finest desktop date 
planner! Here’s the big board, already loaded with user stories broken 
down into 20-work-day iterations: 


pa*tc Ri^ivU Mair>a5cmcir>*t 
(DRM) mdludcd 


Uscv- s*tov»cs 
-fov I 七 evaticw 


Ra\rt o-p -the big boc)\rd oh 
you\r v/dll -Pv-orw Chapter* Z 



how loh^ usc\r s-fcovy 
will take "to develop 
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user stories and fas/cs 



E%ettctSe 


It’s time to get you and your team of developers working. Take each of 
the iSwoon user stories for Iteration 1 and assign each to a developer 
by drawing a line from the user story to the developer of your choice... 




Lauva, 



Bob, dcvclopcv 


SdJL bl^k bel-t 


Ul f 
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break up user stories into tasks 



Wait a second, we can’t just assign user stories to 
developers; things aren’t that simple! Some of those 
user stories have to happen before others, and what if 
I want more than one developer on a single story? 


Your work is more granular than your user stories. 


Your user stories were for your user] they helped describe exactly what you 
software needed to do, from the customer’s perspective. But now that it’s 
time to start coding, you’ll probably need to look at these stories differently. 
Each story is really a collection of specific tasks, small bits of functionality 
that can combine to make up one single user story. 


A task specifies a piece of development work that needs to be carried out 
by one developer in order to construct part of a user story. Each task has a 
title so you can easily refer to it, a rough description that contains details 
about how the development of that task should be done, and an estimate. 
Each task has its own estimate and — guess what — the best way to come up 
with those estimates is by playine plannine poker again with your team. 


by placing planning^ 

叫 e 七士 $ 上 


stovtcs m 


CV^afbcv- 2-, \i 


uscv 

ovks -fov *too. 


r^l^rpei your pencil 


Now it’s your turn. Take the user story of creating a date and break it into tasks 
you think you and your team need to execute. Write one task down on each of 
the sticky notes, and don’t forget to add an estimate to each task. 
















































user stories and fas/cs 


Vo your tasks add up? 


Did you notice a possible problem with your estimates? We’ve got a user 
story with an estimate, but now we’re adding new estimates to our tasks. 
What happens when the two sets of estimates don’t agree? 



0 ^ davs 

_ Bo-tK o( -tKcsc cs*twa*tcs_ 少 

be 七…咖七？ 


Task estimates add confidence to user 
story estimates 

Your user story estimates kept you in the right ballpark 
when you were planning your iterations, but tasks really add 
another level of detail specific to the actual coding you’ll do 
for a user story. 

In fact, it’s often best to break out tasks from your user 
stories right at the beginning of the estimation process, if 
you have time. This way you’ll add even more confidence 
to the plan that you give your customer. It’s always best 
to rely on the task estimates. Tasks describe the actual 
software development work that needs to be done and are 
far less of a guesstimate than a coarse-grained user story 
estimate. 


Break user 
stories into 
tasks to actct 

CONFIDENCE 


to your estimates 
anct your plan. 

Ay>a cavl'.cv you 


do -tWis, i\^t 
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tasks have estimates 


(^Jharpen your pencil 

Solution 


You were asked to take the user story of creating a date and break 
out the tasks that you think you and your team will need to execute 
to develop this user story, not forgetting to add task estimates... 


y ou v -task dcst “?⑽ should 

V^ave just cy\o\aO^\ 

{jo dtstr\\)t actual 

dcvclofwcyrt >wov-k is. 


Task I 

Cxtd^t a. date.^l3ss 


Title ： 


Create 

Est ： ..U •鄉 . 

priority ： . 



i^s 0 ^ ayrC 

: fevt Wt as 

as an w 

s W/s WW 樹 


Task Z 

.Create USC\T 

ii». . view, dhd 
edit a daic 


t 





- 

Task 3 


Cvcatc sterna 


-fov s*bovm(\ dates a... 






f^k 午 

Vcatc. S^L Sdjripts 
ro\r addihg, -fihdihj ; 

、 y}d. upda*tmg date 

■cdovds 


Z 



My tasks add up to a new estimate for my user story, so 
were my original user story estimates wrong? 

Well, yes and no. Your user story estimate was accurate 
enough in the beginning to let you organize your iterations. Now, with 
task estimates, you have a set of more accurate data that either 
backs up your user story estimates or conflicts with them. 

You always want to rely on data that you trust, the estimates that you 
feel are most accurate. In this case, those are your task estimates. 

How big should a task estimate be? 

Your task estimates should ideally be between 1/2 and 5 days 
in length. A shorter task, measured in hours, is too small a task. A 
task that is longer than five days spreads across more than one 
working week, and that gives the developer working on the task too 
much time to lose focus. 


What happens when I discover a big missing task? 

Sometimes—hopefully not too often—you’ll come across a 
task that just breaks your user story estimate completely. You might 
have forgotten something important when first coming up with the 
user story estimates, and suddenly the devil in the details rears its 
ugly head, and you have a more accurate, task-based estimate that 
completely blows your user story estimate out of the water. 

When this happens you can really only do one thing, and that’s adjust 
your iteration. To keep your iteration within 20 working days, you 
can postpone that large task (and user story) until the next iteration, 
reshuffling the rest of your iterations accordingly. 

To avoid these problem, you could break your user stories into tasks 
earlier. For instance, you might break up your user stories into tasks 
when you initially plan your iterations, always relying on your task 
estimates over your original user story estimates as you balance out 
your iterations to 20 working days each. 
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user stories and fas/cs 


Plot just the work you have left 

Remember that burn-down rate chart from Chapter 3? Here’s where it starts to help us 
track what’s going on in our project. Every time we do any work or review an estimate, we 
update our new estimates, and the time we have left, on our burn-down chart: 



zo 


Days Ic-f-t 
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tasks on your board 


Add your tasks to your board 


You and your team are now almost ready to start working on your tasks, but first you need to 
update the big board on your wall. Add your task sticky notes to your user stories, and also add 
an In Progress and Complete section for tracking tasks and user stories: 






ov 


S-t'itkY 
av-c 

-basks ； *tKcy ^ 
ov\ 

uscv- s*bov-Y 七 ^ 
kcloh^ *to- 



This is 


\y\ P\rpvcss 
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IjKc on^'mal usev sto^ 
estimates art myj … 
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i：i rC: 斗•够 


ahd how youVc \rdyihg Oh 
the ^ombihed estimates of all 
■ o( "the -tasks -fo\r all -the usc\r 
sto\fi« -Pov- -the itev-ati Oh. 
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user stories and fas/cs 


TW,s .s^-t a v^-tual kwd 一七 should be a 
kullctrn y/Witcboa^rd ‘ ㈣ so^cv/^c, I.Kc 
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moving tasks to in progress 


Start working oh your tasks 

It’s time to bring that burn-down rate back under control 
by getting started developing on your first user story. And, 
with small tasks, you can assign your team work in a 
sensible, trackable way: 




All the -tasks -fv-om 

m ■听二 a : 


tWeiqre no ^ 

Dumb Questions 


How do I figure out who to assign a task to? 

There are no hard-and-fast rules about who to give a task to, 

but it’s best to just apply some common sense. Figure out who would 
be most productive or—if you have the time, will learn most from a 
particular task by looking at their own expertise—and then allocate 
the task to the best-suited developer, or the one who will gain the 
most, that’s not already busy. 

Why allocate tasks just from the first user story. Why not 
take one task from each user story? 


One good reason is so that so that you don’t wind up with five 
stories in a half-done state, and instead can wrap up a user story 
and move on to the next. If you’ve got one story your other stories 
depend on, you may want to get all that first story’s tasks done at 
once. However, if your stories are independent of each other, you 
may work on tasks from multiple stories all at the same time. 

I’m still worried about that burn-down rate being way up, 
is there anything I can do right now to fix that? 

A burn-down rate that’s going up is always a cause for concern, 
but since you’re early on, let’s wait a bit and see if we catch up. 
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user stories and fas/cs 


A task is only m progress 
whew ifs JN PROCESS 

Now that everyone’s got some work to do, it’s time to move those 
task stickies off of user story cards, and onto the In Progress 
area of your big board. But you only put tasks that are actually 
being worked on in the In Progress column — even if you 
already know who’ll be working on tasks yet to be tackled. 



User s-torics 


Title 


Createfdate 

■…- User creates 


Task 午 


/WDE 


Crea-tc ^ucvics 
•fov dddih^, 

upda-t'm^ da-ie 
v-cdovcls 



Z 


|y> Froyrcss 


I 


TW.s 

smdc '*b s 

yxoi yei kccyv 

Y/OV"kcd OV\) '*t 

s*taY s oVCV " ^ cv " c， 




Task I ^ 

a dale tlass 

从 at 


% 



Task3 


/VIDE 


Cv-ca-bc -t^c sdV»cr«a 

-fov s-tovin^ d3"tcs in d 
da-tabasc 


1 


TiH 〜 


0 


Your board’s only as VALUABLE 
as it is ACCURATE 

If you want to know where you are on a 
project, you have to make sure your board 
reflects reality. If Mike is assigned to 
work on two tasks, but he’s only actually 
working on one, then only one task gets 
put up in the In Progress area. Otherwise, 
it looks like more is being worked on than 
really is. 
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multiple tasks at the same time 


What if Ym working on two things at owcg? 

Not all tasks are best executed in isolation. Sometimes two tasks are related, 
and, because there is so much overlap, it’s actually more work to tackle one, 
and then the other separately. In these cases the most productive thing to 
do is work on those tasks at the same time... 



Both -these iasks involve 
，h this 

be allowed bo-th o-P ih C s C 


Sometimes working on both tasks at the 
same time |S the best option 

When you have two tasks that are closely related, then 
it’s not really a problem to work on them both at the 
same time. 

This is especially the case where the work completed in 
one task could inform decisions made in the work 
for another task. Rather than completing one task and 
starting the next, and then realizing that you need to do 
some work on the first task again, it is far more efficient 
to work both tasks at the same time. 


' r) J Rules of Thumb- 

■ Try to double-up tasks that are related to 
each other, or at least focus on roughly 
the same area of your software. The less 
thought involved in moving from one task 
to another, the faster that switch will be. 

■ Try not to double-up on tasks that have 
large estimates. It’s not only difficult to 
stay focused on a long task, but you will 
be more confident estimating the work 
involved the shorter the task is. 
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user stories and fas/cs 



E%ettciSe 


Someone’s been tampering with the board and things are a real mess. Take a 
look at the project below and annotate all of the problems you can spot. 



SCV" 


series 


Title ： 


Createf date 


User creates 


Task 午 


/VIDE 


Crea-tc £6^L ^ucvics 
•fov dddih^, 
and upda-tih^ da 七 e 
v-cdovds 


ntie ： Send flowers 
Description ： User chooses 
awd sewds via site 


|y> Process 


Task Z 

Cvca-tc user ih-tcr-Padc 
■fco c\reaie, view ar>d 
edii a dale 


Task3 


WB 


Task I ^ 

a date tlass 

6o^ta'ws eve 灼 


Cv-ca-bc -t^c stV»cr«a 
-fov s-bovm^ *m d 
database 










Mark (MVB) 



Lauv-a (UU6j) 



(WP) 
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keep communication flowing with daily standup meetings 




Exe(u：iSe 


Your job was to to take a look at the project below and annotate 
all of the problems you could spot … 



SCV" 


series 


:挪卜 Process 

"t be \v\ y^oojrcss^ 


Title 


Create 

User creates 


Task 午 


/VIDE 


Crcaie S 公 L Queries 
•fov- addm^, 
a^d u^dd'Lih^ dsi,e 
v-cdovcls 


11 


Title: 


Send flowers 
Description ： User ohooses 
buMch aiid S ewds via site 


*4 - by\S t3 s ^ s 

There ^ a l n ^\s o^c. - 

Most - 
• mto 


Task Z 

Cv-ca-tc user ih-tev-Padi 
■fco trcaic, view a^d 
edi-t a da-te 



Bv)t 


Task^ 


A/lPE I 


5 


Cv-ca-bc -b^c stV»cr«a 

-fov S'tovin^ da*tcs in 3 

database 


七 Vv 


Z 


■cate a date tiass 
,al “ 山⑽ eve 七 


be wo\rtli 

dohside\rih0 i 

b\rcakihg -the taskL- 一一 


Task 7 BJD 

《Chd Crv\ai| -fco -Plovist 







，仏 k docs^i CVCh 
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Lauv-a (UU6j) 


Bob (WP) 
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user stories and fas/cs 



^ 7 如 3 ，吐 yo . 

doh -t cv Ch have U c 

s, i dowh. 


Your first stawdup meeting 

You’ve now got some tasks in progress, and so to keep everyone in the 
loop, while not taking up too much of their time, you conduct a quick 
standup meeting every day. 



G'morning everyone, ifs day 1 and I thought rd call 
a quick meeting so we can update the board and 
get everything set for todays development... 


Mark: So, we’ve all had our tasks for one day now. How are 
we doing? 

Bob: Well, I haven’t hit any big problems yet, so nothing 
new really to report. 

Mark: That’s great. I’ve had a bit of success and finished 
up on the scripts to create tables in the database... 

Laura: Things are still in progress on my user interface task. 

Mark: OK, that all sounds good, I’ll update the board and 
move my task into Completed. We can update the burn rate, 
too; maybe we’re making up for some of that time we lost 
earlier. Any other successes or issues to report? 

Bob: Well, I guess I should probably mention that I’m 
finding creating the right Date class a little tricky... 

Mark: That’s fine. I’m really glad you brought it up, though. 
That’s a two-day task and we need it done tomorrow, so I’ll 
get you some help on that as soon as possible. OK, it’s been 
about seven minutes, I think we’re done here... 


Your daily standup meetings should: 


■ Track your progress. Get everyone’s 
input about how things are going. 

■ Update your burn-down rate. It’s a 
new day so you need to update your 
burndown rate to see how things are 
going. 

■ Update tasks. If a task is completed 
then it’s time to move it over into the 
Completed area and check those days 
off of your burn-down rate. 

■ Talk about what happened yesterday 
and what’s going to happen today. 


Bring up any successes that happened 
since yesterday’s standup meeting and 
make sure everyone knows what they’re 
doing today. 

■ Bring up any issues. The standup 
meeting is not a place to be shy, so 
encourage everyone to bring up any 
problems they’ve encountered so that 
you all as a team can start to fix those 
problems. 

■ Last between 5 and 15 minutes. Keep 
things brief and focused on the short¬ 
term tasks at hand. 


A daily standup 
meeting skould 
keep everyone 
motivated，keep 
your toarct up-to- 
ctate, and kigkligltt 
any problems early> 
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doing your first task 


Task 1: Create the Pate class 

Bob’s been busy creating the classes that bring the “Create a Date’’ user story 
to life, but he needs a hand. Here’s a UML class diagram that describes the 
design he’s come up with so far. 


A UA^L- dl^ss 

shows -the Masses i h you^* 

so 不七 and Kow "they 

relate "to othev-. 


The Pate class is split into three classes, one class for each type of date... 

f/TH 洳 d 

, ,h ah 沾 5 心此 £ 1 )如 

VaU 


：hookaw 


Cheeks that the 
啊 i(icd cvch-t 
is allowed oh -this 
date. 




* 今士 ㈣ * : 


£e6o 灼 dPa 七 c 


丁 W»v"dPa*tc 


# val*idatcEvc^t(cvc^t 


o 



It’s okay if you’ve never 
' t seen UML before! 

[V 上 Don’t worry if you don’t know 

your UML class diagrams 
from your sequences; there’s a short overview 
in Appendix i to help you get comfortable with 
UML notation as quickly as possible. 


Pcpchdihg oh the daic the 

f°^ r d r cvc ^ ^i^cd will 

be di+4-cv-cht 
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TV task m ^ojrcss 
ov\ feoavd- 


user stories 



Each Pate can then have a number of Events added to it 



Vou have £ Wo 
糾 W£ i ypcs ^ 
〜沾 oh a Z)^c. 



What do you think of this design? 
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bringing your design to life with a sequence diagram 



^ that k— objects 

2° showmg how they wovk 
together io make mtcvad：i 0h 

—r 


Task 1 ： Creating dates 


TV^C vascv 

i\\t ^ otcss W 

treat— a 灼 c>w 


Let’s test out the Date and Event classes by bringing them to life on a sequence diagram. 
Finish the sequence diagram by adding the right method names to each interaction between 
objects so that you are creating and validating that a first date that has two events, going to a 
restaurant and seeing a movie. 
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ser stories and tasks 



丁 he maghcts io 
"the method ca\\s 


oh 


Task / BJD 

a daic dass 
仏 <s£ doirtains cvchis 


| goOnDate^^^^^^ 





seeMovie(date : Date, address : Address) 


new SeeMovieEvent() 








method hdme. 



| validateEvent(event : Event) : boolean ■ 





getName() : String 







^oToRcs-tauva^-tBvc^-t 




1 SccMovicEvc^i 






f V ouVc y\oi suve 

wOVC 


d»ayaws i\\crc 
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exercise solution 



Bte(tciSe 

SoLyiiOH 


Your job was to test out the Date and Event classes by bringing them to life 
on a sequence diagram. You should have finished the sequence diagram so 
that you plan and go on a first date with two events, going to a restaurant and 
seeing a movie. 



Tiic method tails 
av-c Aov\t for you. 


TV^c date >f 
is asked -to ^ 
sc*t 

buo 


, c|ics ^ ^ 
datc ob j^i M 
liUlc bHUlc 
dcsigh- w jsc. 



pmallyi v/V^c^ all cvcr\*U av-c 

added validated ； you 63 r\ 

OY\ yoiAV" da-tef 
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j^^^oojrcss 

Task f BJD 

a daie dass 
七七 £oh*tc)i^s cvch^ts 


z 


T\\t date tv-ca*tcs tacM Jc 

■tiic cvcr\*ts i*tscl-f> addrn^ 

七 hem *to i*ts lis 七 J cvcr\*U- 



You Aor：i 叫 k»tlY ertait ^ ev ⑶ t; events arc all 
seated tV.c skm o-f a date. 



da > 3 士 ^ h 一 J 
^ of -the cv Ch -ts so they 

S ^"r P f Cd 吵 i^Uhe 
dale S I,si of allowed cv Ch ^. 


SccMovicEvc^i 


丁 he events -themselves 
patty simple, all ihey khow 
is ihai they av-c cvchts. 
T'hcy doh't cveh khow what 
dates -they av-c allowed Oh. 
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monitoring your progress 


Stawdup mcetlwg: Pay 5, ewd of Week 1 


So, one day left in the first 
week, how are we doing 
according to the big board? 


Bob: Well, I finally got the date class finished with a little 
help, ran late by a day though... 

Laura: That’s OK, this time around. We can hopefully 
make some of that time up later. 

Mark: All work on the database is now done; I’m all set 
for the next set of tasks. 

Laura: Great, and I got my work done on the user 
interface pieces, so we’ve actually got something running. 

Bob: Always a good week when you head out of the office 
with something working". 

Laura: Absolutely. OK, it’s time to update the board and 
our burn-down rate to get things set up for next week. 
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thereiare no o 

Dumb Questi9ns 


Do I REALLY have to get everyone to stand up during a 
standup meeting? 

No, not really. A standup meeting is called “standup” because 
it is meant to be a fast meeting that lasts a maximum of 15 minutes; 
you should ideally be aiming for 5 minutes. 

We’ve all been stuck in endless meetings where nothing gets done, 
so the idea with a standup meeting is to keep things so short you 
don’t even have time to find chairs. This keeps the focus and the 
momentum on only two agenda items: 

• Are there any issues? 

• Have we finished anything? 

With these issues addressed, you can update your project board and 
get on with the actual development work. 

An issue has come up in my standup meeting that is 
going to take some discussion to resolve. Is it OK to lengthen 
the standup meeting to an hour to solve these bigger problems? 

Always try to keep a standup meeting to less than 15 minutes. 

If an issue turns out to be something that requires further discussion, 
then schedule another meeting specifically for that issue. The 
standup meeting has highlighted the issue, and so it’s done its job. 


Do standup meetings have to be daily? 

It certainly helps to make your standup meetings daily. With the 
pace of modern software development, issues arise on almost a daily 
basis, so a quick 15 minutes with your team is essential to keeping 
your finger on the pulse of the project. 

Is it best to do a standup meeting in the morning or the 
afternoon? 

Ideally, standup meetings should be first thing in the morning. 
The meeting sets everyone up for the day’s tasks and gives you time 
to hit issues straight away. 

Still, there may be situations when you can’t all meet in the morning, 
especially if you have remote employees. In those cases, standup 
meetings should be conducted when the majority of your team begin 
their working day. This isn’t ideal for everyone, but at least most 
people get the full benefit of early feedback from the meeting. 

On rare occasions, you can split the standup meeting in two. You 
might do this if part of your team works in a completely different time 
zone. If you go with this approach, keeping your board updated is 
even more critical, as this is the place where everyone’s status from 
the standup meeting is captured for all to see. 


Stanctup meetings keep 
your peers, employees, and 
managers up to date，amt 
keep your finger on tke pulse 
ol kow your ctevelopment 
work is g[oing[t 


BULLET POINTS - 

■ Organize daily standup meetings to make 
sure you catch issues early. 

■ Keep standup meetings less than 15 minutes. 

■ A standup meeting is all about progress, 
problematic issues, and updating your board. 

■ Try to schedule your standup meetings for the 
morning so that everyone knows where they 

are at the beginning of the working day. 
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updating your project board 



E%enciSe 


It’s the end of Week 1 ， and you and the team have just finished your standup meeting. It's time 
to update the project board. Take a look at the board below and write down what you think 
needs to be changed and updated on the board to get it ready for Week 2. 


User s-borics 



\y\ Pv-oycss 


Task Z 

LU^ 

Create user 

init)r(ate 

io treaie, » 

ew jnd 

n 



«tw»s -task IS 6omflc*tc- 


— — — — — — — 










_ — — — — — 








_ 






_ 
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3 u\rh Pov/h 


午弓 


7 



Work 
lrf 七 


ZO- 


V\ov/ wudh 

^ovk V^as \)ttY\ Aor\t, 

v/V\a*t do y ou 
七 V\c y\ev/ buvvx-d 0 ^^ 
va*tc should kc? 


All these tasks av-c o-f^idially 

Complete, -too. 


O 


ID 


15 10 5 

Days lc-f*t 


O 




Completed 


Thmk you r>ccd *to move 

m heve yc*t? 
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updating your project board 



fLon% E%eiiciSe 
SotlitiON 


You were asked to update the board and write down what you think needs to be changed to 
get it ready for Week 2. 


User s-borics 


\y\ ?royrtss 


this -task 
Aoy\t, 3 iy \ Ch*tivc 
s-to\ry is dorwplc-tc. 
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Corbie 七 c 


BuVh Dov/y\ 



Work 

lrf 七 
10 


TV\c v\t^i Ww 
dovm v3*bc 3*t 
七 hC tr\A 
v/cck I 



Completed tasks 
Jo hc\rc Uhtil -the 
usc\r s-fco\ry itscl-f is 
Completed. 






ID 


15 10 5 

Days le-ft 


O 



|-f a usev- s*tovy 

kumped -from i\\t rtcwbcm, 七 Wi 
is y/Kcv*C Y ou ^ 七 1 七 . 




Completed 


Ov\\y domplctc user sWiCS, 

3 灼 d -theiv vcat'tathcd 

tasks, arc allowed m -the 
Completed sfa^c- 


Create a date . 


-rwj 

問 _ ■ Z _ ■ W ; 麻 - 


\ Cveat* 3 datt 〜也 “:*■ • m ^ S£e ■ — :⑽ 1 

(or adding 1 

and wfdat'na <^ e 1 

■沾 “date ■ ■ 

1 1 - | - | 

reiords ■ 


TWis usev- sW/ is 
1 townie 七 ed. 



all *tKc -tasks badk 
*to -t^c usev- s*tovy *to keep 
cvcv-ytKmg -to^c-thcv-. 
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into the second week 


Stawdup mcetlwg: Pay l. Week l.. 


o-f *tV^c k 

Pv-o^v-cs -tasks 
•^vow 七 V^c to3v*d* 




wtihg 

3s ^ team lead ； 
Ic^s-t oh "this 
'"tc^a-tioh. 


Hey guys, I've been busy working on my task 
and I noticed a way of saving us some time 
and effort by extending our design a little... 




Laura: How are you going to do that? 

Bob: Well, if you treat someone ordering flowers as just 
another type of event, then we can add it straight into our 
current class tree, and that should save us some time in the 
long run. 

Laura: That’s sounds good. What do you think, Mark? 

Mark: I don’t see any problems right now... 

Bob: Apart from it might take an extra day right now to 
make the changes, but in the long run this should save us 
some time. 

Laura: Mmm. We’re still a little behind, but we can 
probably lose a day on the burn-down rate now if it saves us 
time later on in the iteration. OK, I’m sold, let’s go for it... 


The ^ah 9 c ih^i 
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E%ettctSe 


What refactoring do you think Bob is talking about? Take the class hierarchy below and circle all 
the things that you think will need to change to accommodate a new OrderFlowers event. 



How many classes did you have to touch 
to make Bob’s changes? 


Are you happy with this design? Why or why not? 
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detecting problems with the design 


SoLuiiOH 


You were asked to take the class hierarchy below and circle all the places that you think will 
need to change to accommodate a new OrderFlowersEvent … 



r | W， | ， 

仏 e J allowed 3 

cvehts i h cvclr y sj (c 

七 ype d day 




How many classes did you have to touch 

to make Bob’s changes? Bye dasscs y/c\rc oy- added *b> add juft -this o^c nev/ *t^fpc 

Fiv-s*t u 0v-dc\rFlowc\rs£vcir\*t w dass needed bo be added ； By\A methodi h> ov-dev- -Plov/cv-s 

oy\ a da*tc needed h> be added h> 七 he Da*tc dass. Finally I had h> update cb(M o( -the *typcs o( 

date *to allow, ov- vcjcd*t ； *thc new *tyj>c c^f eve 灼七 dc^c^dmg oy\ y/hc*thcv i*t’s allowed 七 ha 七 da*tc ov- 的。 七 

Are you happy with this design? Why or why not? 

Five classes bcinj dha^ed seems like a LOT y/hc^ all add'm^ is ONE new cvc^t happens whe 的 | have 
*to add ； say ； d v\tvi *typcs o-f cvc^*tj is i*t dlv/dy s 50^5 *to involve 七 his mudh y/ov-k? 
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All done. It took a bit of work but we now have a 
Send Flowers event that you can add to a date. 



Laura: Hey, isn’t “Buy jewelry” coming down the 
line? That works as just another event, too, right? 

Bob: Yeah, but we’ll need to add some time to make 
those changes to all the classes again. 

Mark: Can’t we come up with a more flexible design, 
so we can avoid this pain and effort each time we add 
a new event? 

Bob: That’s exactly what I was thinking. 

Laura: But that will take even more time, right? I 
guess we’re invested, though, huh? This will save us 
time later, I hope... 






A/ork 

id 七 


BuV"h Powh 


心 ~' The hew buirh vatc ai the 

3 午 引 ad Week 1. Things avc 

9° ,h 9 "the wv-ohg way. 


zo 


o 


10 


1*5 10 ^ 

Pays Ic-Pt 


0 
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si/rp/vses". 


Wc interrupt this chapter... 

You’re already getting behind on your burn-down rate 
and then the inevitable happens: the customer calls 
with a last-minute request... 


Hey! The CEO of Starbuzz just 
called, and he wants to see a demo 
of ordering coffee as part of a date 
Can you show me that tomorrow? 


^us-to^cv, 

'^woohs CBO 
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You have to track unplanned tasks 

So far, your board has kept track of everything going on in your 
project. But what happens when somthing unplanned comes up? You 
have to track it, just like anything else. It affects your burn-down rate, 
the work you’re doing on user stories, and more... 

Let’s take a look at a part of the board we haven’t used yet: 




——I —- 




a vcd 

wst l^ke ^ task. 

，以 ‘ placed ^ s ks. 


，仏 e uhplahhcd iask 
,s b 〜 3 worked oh, i-t 
•^oves ih-fco /h Pv-ojvcss. 



c%tva user sW 


An unplanned task is STILL a 
task. It kas to te tracked, put in 
progress, completed, and incluctect 
in tke Lurn-ctown rate just like 

EVERY OTHER TASK you kave. 
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dealing with unplanned tasks 


o 


0 



Wait a sec! Youre saying we have 
to do the demo? What if it blows our 
deadlines? 


Talk to the customer 


以南 dcad ' mC ? 


You’ve been hit by the unexpected, but that’s part of software 
development. You can’t do everything, but you also can’t make the 
choice about what takes priority. Remember, the customer sets 
priorities, not you. 

You need to deal with new tasks like customer demos, and the best 
way to do this is to ask the customer what takes priority. Give the 
customer a chance to make a considered decision by estimating the 
amount of work that the new task requires and explaining how that 
will affect the current schedule. Ultimately, the customer rules, so as 
long as they have all the information needed to make a choice, then 
you need to be prepared to go with their decision by reshuffling your 
existing tasks and user stories to make room for the surprise work. 

Ultimately you need to keep your customer in the picture as to what 
is in and what is out. Adding new unplanned work is not the end of 
the world, but your customer needs to understand that the work has 
an impact, and then they can choose what that impact is. 


f 


l-p i\\t tusWcv- 
y/ar\*b *tV^c dcw'O, 
vou y\ccd "to 

u\>da*tc Y ouV " 
board a^am- 


TW»s *task 

OY\ pUSC … 



… "to make \roortn -fo\r "the 

new task. 




10 MVB 

Md o^rdtY doffee 
event ahd send 
by e^ail -to 
S-ta\rbu ： 










You *to move sW»cs *to 

_七 *, .s okay, as Ua 

as-tKc tusWcv* uhdcrsla^ds tKats the 
\^ci Atc\s\o^ 
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Unexpected tasks raise your burw-doww rate 

Unexpected task mean extra work. If the unexpected tasks can’t 
be pushed into another iteration, then they need to be factored 
into your board. All of this means that your burn-down rate is 
affected, and not in a good way... 


Bu\ry> Pov/h 



was 认？ 

alv-cad7, amd 

wove 

flawed 


Pays 




^ ca\^\aicd velocity 

wheh pbhhihg ouv- 

a 咖 s. 
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velocity doesn’t account for surprises 


Velocity helps, but... 

You’ve got more work thanks to some unexpected requirements from your 
customer, but didn’t you factor this in when you calculated your team’s 
velocity? Unfortunately, velocity is there to help you gauge how fast your 
team performs, but it’s not there to handle unplanned tasks. 


Wc origmally calculated velocity as... 



>c to 


% 


Tiic o-f 

people m youv 七 Cdrw 





V^>uV" 七⑸ hf/s 七 

P ass vcl 。 乙 ity, whidh 

,s adtually a ^ucss 
at this poiht 


this ec^ahoys 

Chap-tcv- l? 


午 z 


TKc amourrt d y/ovk *m 
days youv -team tBv\ 
iidv>dle'm oY\t i 七 evatio 灼 


So we have this much "float" 


I >C zo -午 z 二 10 


t ft 


一 糾 — 

c f ou,d i-P 

Wo " kcd ^ > 00 % vet J liy 

but it may not be enough! 


Float — the “extra” days in your 
schedule — disappear quickly. 

An employee’s car breaks down, someone has to go 
to the dentist, your daily standup meetings...those 
“extra” days disappear quickly. And remember, 
float is in work time，not actual time. So if 

your company gives an extra Friday off for great 
work, that’s three days of float lost because you are 
losing three developers for the whole day. 

So when unplanned tasks come up, you may be 
able to absorb some of the extra time, but velocity 
won’t take care of all of it. 
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ihereictre no 。 

Dumb Questions 


You said to add unplanned tasks as red sticky notes. Do I 
have to use colored sticky notes? And why red? 

We picked red because regular tasks are usually on regular 
yellow sticky notes, and because red stands out as a warning color. 
The idea is to quickly see what’s part of your planned stories (the 
normal stickies), and what’s unplanned (red). And red is a good “alert” 
color, since most unplanned tasks are high-priority (like that customer 
demo that came out of nowhere). 

It’s also important to know at the end of an iteration what you worked 
on.The red tasks make it easy to see what you dealt with that wasn’t 
planned, so when you’re recalculating velocity and seeing how good 
your estimates were, you know what was planned and what wasn’t. 

So later on we’re going to recalculate velocity? 

Absolutely. Your team’s velocity will be recalculated at the 
beginning of every single iteration. That way, you can get a realistic 
estimate of your team's productivity. 0.7 is just a good conservative 
place to start when you don’t have any previous iterations to work 
from. 

So velocity is all about how me and my team performed in 
the last iteration? 

Bingo. Velocity is a measure of how fast you and your team 
are working. The only way you can reliably come up with a figure for 
that is by looking at how well you performed in previous iterations. 


I really don’t think 0.7 captures my team’s velocity. Would 
it be OK to pick a faster or slower figure to start out with? Say 
0.65, or 0.8? 

You can pick a different starting velocity, but you have to stand 
by what you pick. If you know your team already at the beginning of a 
project, then it’s perfectly alright to pick a velocity that matches your 
team’s performance on other projects, although you should still factor 
in a slightly slower velocity at the beginning of any project. It always 
takes a little extra time to get your heads around what needs to be 
developed on a new project. 

Remember, velocity is about how fast you and your team can 
comfortably work, for real. So you’re aiming fora velocity that you 
believe in, and it’s better to be slightly on the conservative side at the 
beginning of a new project, and then to refine that figure with hard 
data before each subsequent iteration. 

Velocity is NOT a 
substitute lor good 
estimation ； it’s a 
way oi factoring 
in tke real-world 


perlormance ol you 
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you know where you are 


Wc have a lot to do... 


You’re in a tough spot. Doing some refactoring work is going to 
cost you time now，but the hope is that it will save you time in the 
long run. In addition you have the new demo that you need to 
prepare for the iSwoon GEO.... 


You've got more work to do 





w °" k ^ 
ihc ihai 


ttt 


and your burn - down rate is going iw the wrong direction. 


1 


Bum Povm 

糾 almost ^ 

★ f &Y 

started ⑽七、 



|«5 10 5 

Days Ic-ft 
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but we know EXACTLY where wc stand 


The customer T^nows \diere you are 

At every step you’ve kept the customer involved so they know 
exactly what work they’ve added, and you can show them 
exactly what the changes will impact. 


YOU ^now wiere you are 


You and your development team are also on exactly the same 
page thanks to your board and the burn-down rate. This 
means that although things look a bit bleak, at least no one is 
burying their heads in the sand. The challenges are right there 
on your wall. 


Successiul software 
development is about 
knowingf vkere you are. 


You know there are challenges, NOW . 

Because you’re monitoring your project using your board 
you know right now that there are challenges ahead if 
you’re going to keep things on track. Compare this with the 
Big Bang “See you later, I’ll deliver something in 3 months” 
’ approach from Chapter 1. 



With the Big Bang approach, you didn’t know you were in 
trouble until day 30, or even day 90! With your board and 
your burn-down rate you know immediately what you’re 
facing, and that gives you the edge to make the calls to 
keep your development heading towards success. 


Witk an uncterstanctingf 
oi your progress and 
ckallenges, you can keep 
your customer in tke loop ， 


and cteliver software 
wken it’s needect. 


Sometimes you'll heav- 
this irc-fcmrcd io as the 

All is far from lost! Well tackle all these problems 
in Chapter 5, when we dig deeper into good class and 
application design and handle the customer demo. 
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meet velocity 



This week’s interview: 

Keeping pace with Velocity 


Head First： Welcome, Velocity, glad you could make 
time in your busy day to come talk with us. 

Velocity： My pleasure, it’s nice to be here. 

Head First: So some would say that you have the 
potential to save a project that’s in crisis, due perhaps 
to surprise changes or any of the other pieces of extra 
work that can hit a plan. What would you say to those 
people? 

Velocity： Well, I’m really no superhero to be honest. 
I’m more of a safety net and confidence kinda guy. 

Head First： What do you mean by “confidence ”？ 

Velocity： I’m most useful when you’re trying to 
come up with realistic plans, but not for dealing with 
the unexpected. 

Head First： So you’re really only useful at the 
beginning of a project? 

Velocity： Well, I’m useful then, but at that point 
I’m usually just set to my default value of 0.7. My 
role gets much more interesting as you move from 
Iiteration 1 to Iteration 2 and onwards. 

Head First： And what do you offer for each 
iteration, confidence? 

Velocity： Absolutely. As you move from one iteration 
to the next you can recalculate me to make sure that 
you can successfully complete the work you need to. 

Head First： So you’re more like a retrospective 
player? 

Velocity： Exactly! I tell you how fast you were 
performing in the last iteration. You can then take 
that value and come up with a chunk of work in the 
next iteration that you can be much more confident 
that you can accomplish. 


Head First： But when the unexpected comes along... 

Velocity： Well, I can’t really help too much with 
that, except that if you can increase your team’s 
velocity, you might be able to fit in some more work. 
But that’s a risky approach... 

Head First： Risky because you really represent how 
fast your team works? 

Velocity： That’s exactly my point! I represent how 
fast your team works. If I say that you and your 
team, that’s 3 developers total, can get 40 days of 
work done in an iteration, that’s 20 work days long, 
that doesn’t mean that there’s 20 days there that you 
could possibly use if you just worked harder. Your 
team is always working as hard as they can, and I’m 
a measure of that. The danger is when people start 
using me as a pool of possible extra days of work... 

Head First: So, if you could sum yourself up in one 
sentence, what would it be? 

Velocity： I’m the guy that tells you how fast your 
team worked in the last iteration. I’m a measure 
of how you perform in reality, based on how you 
performed in the past, and I’m here to help you plan 
your iterations realistically. 

Head First： Well, that’s actually two sentences, but 
we’ll let you get away with that. Thanks for making 
the time to come here today, Velocity. 

Velocity： It’s been a pleasure, nice to get some of 
these things off of my chest. 
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5 good-enougK design 

Getting it done with 

% great design ^ 



Good design helps you deliver. In the last chapter things were looking pretty 
dire. A bad design was making life hard for everyone, and, to make matters worse, an 
unplanned task cropped up. In this chapter you’ll see how to refactor your design so that 
you and your team can be more productive. You’ll apply principles of good design, 
while at the same time be wary of striving for the promise of the “perfect design.” Finally 
you’ll handle unplanned tasks in exactly the same way you handle all the other work on 
your project using the big project board on your wall. 


this is a new chapter 
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bringing iSwoon under control 


(Swoon is m serious trouble... 

In the last chapter things were in pretty bad shape at iSwoon. You had some refactoring work 
to do to improve your design that was going to impact your deadlines, and the customer had 
piped in with a surprise task to develop a demonstration for the GEO of Starbuzz. All is not 
lost, however. First let’s get the refactoring work done so that you can turn what looks like a 
slip into a way of speeding up your development work. The current design called for lots of 
changes just to add a new event: 
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r^lj^rpen your pencil 


good-enough design 


Write down the changes you think would be needed if... 


...you needed to add three new event types? 


*to 


dot l：：' d S 

, zr)C s ortvja\re io 


...you needed to add a new event type called “Sleeping over，’’ 
but that event was only allowed on the third date? 


^rtamly 乙啊 ih ‘dy he 叱 

...you changed the value of the name attribute in 
the OrderFlowersEvent class to “SendFlowers ”？ 


you are here ► 


151 
























detecting bad design 


c^i^rpen your pencil 

Solution 


You were asked to write down the changes you think would be 
needed if... 


■you needed to add three new event types? 

.Wt d y\ttd d hew cvch*t dldss -for of ■the v\ 

. OhC 

Paic dlass 


l heed .3 w cych*t dldss +o\r eddli o+ hey/ *typcs. Three hcv/ mc^ods^ 

h .itype of. cychii. y/ould. heed .ip. be. dddedi. .ip. 土 ix 3bs^\radi ， 押代”士 . 

•. • • .^.Uss. TKch,. cadh. p+. . 七 d3.ii?. classes, Kp>y.cycy：. rna»y. ihcyi?. 3%. Y/ill.. v\ttd . 

ip• !? 《 .uf.d^icd.ito alloy/ loy disallow) the 土“代炙 iyfes of cych.i；. dcpchdih^ 
oh -tKc. cy.c^t.is 3.IJowed. ^9x. .ihdi. .d^ic ： . 

...you needed to add a new event type called ^Sleeping over，” 
but that event was only allowed on the third date? 

A y>^. 广 1 彡 ??. y/puld be added；. .sor^cihnf\9. 运 y. 印七 ” 

method td\\cd ^AccvO^ y^ccd^ io be ^dieted io Paic tUss so 

.. ihc.. 朽 d .cv.c^i. C.9y>. be. addedi. .h>. .9. .ddic：. .B^!!yj. .al.l iKvrec. ^ .ihc. ddic. . 

dasscs.would.^c.cd. ip be. upd^ief!. \y\. oy：dcr ip..spedi-ry. 七 hd 七 only. 七 )> 炙 . Chiv'd.dejic. 

. .aiiows A ^kc^ys^Osc^^i. io. Ip.c. spciti^ic.d- . 

...you changed the value of the name attribute in the 
OrderFlowersEvent class to “SendFlowers ”？ 

All *thv~cc o( 仏 c di-f-fcv-c^*t CorxCi't^t classes o( Da*tc would r\ttd *to be updated so lo^id 七 

decides a pav-*tidulav cvc^*t is al lowed ^ov/ uses *t“c t\t^ 'm v-c^av-ds ito ftc i)Vdc\r1P|oy/c\rs)£vc^it 


dlass^s y\Bv^c attv-ibu-tc value 匕 liaise. Also, *thc value o( Ov-dcv-Flowcv-Evc^ts y/ill r\ttA ix> 匕 
-f\rom ^Ovdcv-Fiov/cv-s^ to ^Sc^dFlov/cv-s/^ ^'maliy -the dldss i^ame y/ill y\ccd to be bo 

Sc^dPlowcv-sEvc^'t so ii follows ttc 匕 ojtw ⑶ fcon wcVc 匕 uvv^tly usmOj fov- didie events- 



Wow, thafs not good...a single change means 
we have to mess with a bunch of classes. Can’t 
we do something about that in our design? 


Well-designed classes are singularly focused. 

The problem here is that for any particular behavior — like sending 
flowers — the logic for that behavior is spread out over a lot of 
different classes. So what seems like a simple change, like the name 
in OrderFlowersEvent being changed to “SendFlowers,” 
turns into a multi-class mess of modifications. 
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good-enough design 


This design breaks the single respowsibility priwclpk 

iSwoon is such a headache to update because it breaks one of the fundamental principles of 
good object oriented design, the single responsibility principle (or SRP for short). 


Single responsibility principle 

Every object in your system should have a 
single responsibility, and all the object’s 
services should be focused on carrying out 
that single responsibility. 


Both the Date and Event class break the single 
responsibility principle 

When a new type of event is added, the single responsibility 
principle states that all you should really need to do is add the 
new event class, and then you’re done. However, with the current 
design, adding a new event also requires changes in the Date class 
and all of its subclasses. 


|-f you add a cvcyrt 

切 pc,add a 

wc*bV\od heve … 


Dale 


allowcdEvCh*ts - 

- - 

+ sccMovicO : void 

+ ^oToRcs-taur) : void 

+ : booledh 

•booled 


ve 



You 

implementect 
tke single 
responsibility 
principle 
correctly wken 
eack ol your 
objects kas 
only one reason 
to ckanget 


: bool can 




TWiv^dPs^tc 






养 valida 七疋咖 七 ( cvc 灼七： E 鄕七) 

: boolean 


养 v / alida 七 e 它鄕七 ( ev ⑼七： 

: boolean 



• •and 七 he 灼 update cath o( -these 
subclasses o-P Date {jo allow or disallov/ 
七 he v\t^j cvcr^-t type- 
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design refactoring 



ExenciSe 


Your design at the moment makes it hard work to add events, change event names, 
and even deal with additional dates. Take a look at the current design and mark up 
what changes you’d make to apply the single responsibility principle to the iSwoon 
design (and in the process, make it easier to add new events and dates). 



yuccas xo , 、 

add a ol cvcht. 
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good-enough design 


R ⑽州 ben taeM dass should be 

y*cs^oir\siblc of\ly 

sKould^t ^rcly on tWy jomj 

'msidc otV^cv dlasscs. 



3vc 


■to dc^dc what cveh-ts a^rc allowed 

咖 a date, bui the 

。+， cvchi ^a^ CS) -the Date 

subclasses have t> ^hah 9 c ; -too. 


- ► Armevs on page 162 . 

If you're feeling stuck, turn the page for more oh 
the single responsibility principle... 


you are here ► 


155 



























srp analysis 


Spotting multiple responsibilies m your design 


Most of the time，you can spot classes that aren’t using the SRP 
with a simple test: 

o On a sheet of paper, write down a bunch of lines like this: The [blank] 

[blanks] itself. You should have a line like this for every method in the class 
you’re testing for the SRP. 

❺ In the first blank of each line, write down the class name. In the second 
blank, write down one of the methods in the class. Do this for each 
method in the class. 

o Read each line out loud (you may have to add a letter or word to get it to 
read normally). Does what you just said make any sense? Does your class 
really have the responsibility that the method indicates it does? 

If what you’ve just said doesn’t make sense ， 
then you’re probably violating the SRP with that 
method. The method might belong in a different 
class — think about moving the method. 


st }ould look like. 


SRP Analysis for 

tW»s bUk, a\\ 

The 

tath method 
-the class ih -this 
, bbhk, Ohc pev lihe. 

itself. 

The 

itself. 

The 

itself. 

:一 

R e? e—e ::广 
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good-enough design 


:^|j^rpeti your pencil 


Apply the SRP to the Automobile class. 


Do an SRP analysis on the Automobile class shown below. Fill out the sheet 
with the class name methods in Automobile, like we’ve described on the last 
page. Then, decide if you think it makes sense for the Automobile class to 
have each method, and check the right box. 



- - 


+ S*ta\rt0 : void 
+ s-fcopO : void 

+ dhahyTi\rcs(*ti\rcs : Tiv-cCJ) : void 
+ dv-ivcO : void 
+ washO : void 
+ dhcdkOilO : void 

+ ytOilO : 


SRP Analysis for 

Au^bomobilc 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 



Follows Violates 
SRP SRP 





^ what you ^ad docs^i 

ma i c L s r , sc； 

° h that lihc is probably 

viobtih 9 the SRP. 
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single responsibility 



Apply the SRP to the Automobile class. 

Your job was to do an SRP analysis on the Automobile class shown below. You 
should have filled out the sheet with the class name methods in Automobile, and 
decided if you think it makes sense for the Automobile class to have each method. 


I 七 makes 
七七七 he 
au*towobilc 

3hr\d 

a -fuy\t*bov> o^* 

七 he au'bow'obilc- 


du^omobilc is 

t!QT v-cspohsiblc 

oy/h turcs, 
washihg itself, 

饮 ^hc^kihg iis 
ov/h oil. 



SRP Analysis for AuWobile 


Automobile 

s*ta\rt[s] 

Automobile 

s*topCs3 

/\u*bomobilc 

dhar\(\csTircs 

Automobile 

driveCs3 

Au*tonr\obilc 

y/ashCcs] 

Automobile 

t\\CtkCs] oil 

Automobile 

<\rtCs] oil 


itself. 

itself. 

itself. 

itself. 

itself. 

itself. 

itself. 


You may have 
■to add av\ u s w 
ov- B wovd ov- 
two "to make 
the sch-tch^c 
readable. 


^0\A Should ^3^C-fully 

dboU*b "tills OY\t) 3^d v/V>3*t 

means. Tii'is is a mc-bV^od 七 ha 七 七 

v*ctuv*y\s 3w>oiAK\"t o*P oil \y\ *c^c 
au-bomobilc-a^d t^at js.somct^'mj 
*tV ^ 七 au-bow'obilc should do. 


V 


Follows 

SRP 


Violates 

SRP 


iThis ohc was a little 

tiruiky—wc thought that 

whilc 如 ^u^obilc miahi 

s iair-t ahd s-top itself, i 仏 
他 lly the vcspohsibilty of 
• d r— io dvivc ih e ^ 


a 


S 逆從 V 


^or^rhoh schsc US，h 3 


y 财 owh cx，_. 
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good-enough design 


&omg from multiple responsibilies to a single responsibility 


Once you’ve done an analysis, you can take all the methods that 
don’t make sense on a class, and move those methods to classes 
that do make sense for that particular responsibility. 


’士 s 3 d\r 


^C\rs 




Au*tor^obile 


\A/c vAsed our a^s 

W 呼 0 d 


+ s*tariO : void 
+ s*topO : void 

+ ^hah^cTi\rcs(*ti\rcs : TircCJ) 
+ dv-ivcO : void — 

+ washOjvoid, 

+ cMtt\cO\\0 : void 

+ gc*tOilO : ih*t 


PvWcv 

十 dv-ivc(a : Au-towobilc) : void 


u to^ob,/ c ^ r 


A Cav-lVash 
dldss tBr\ 
handle washing 
Bv\ du*tomobile- 



+ dha ， TVes(a : Au-tomobilc, iivcs : TiresCJ) : void 


f\loYJ ^\Abori\o\)\\t 

V^as only a sm^lc 

V-Cspo\r\Sik»li*tY ： 
dcdl>^5 »*ts 




ovm 


bdSi£. -fu\r\t*tiO\r\S. 


/\u*tor»\obilc 


+ s*ta\rtO : void 
+ s*topO : void 

+ ytOilO : , m*t 



A is vcspohsiblc (ov 

匕七••代 s ahd 匕 Wmg 
"the oil oh du'tomobilc. 


there J are no 

Dumb Qu 


Questi9ns 


How does SRP analysis work when a method takes 
parameters, like wash(Automobile) on the CarWash class? 

Good question! For your SRP analysis to make any sense, you 
need to include the parameter of the method in the method blank. So 
you would write "The CarWash washes [anl automobile itself.” That 
method makes sense (with the Automobile parameter), so it 
would stay on the CarWash class. 


But what if CarWash took in an Automobile parameter 
as part of its constructor, and the method was just wash()? 
Wouldn’t SRP analysis give you a wrong result? 

It would. If a parameter that might cause a method to make 
sense, like an Automobile for the wash () method on 
CarWash, is passed into a class’s constructor, your SRP analysis 
might be misleading. But that’s why you always need to apply a good 
amount of your own common sense and knowledge of the system in 
addition to what you learn from the SRP analysis. 
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don’t repeat yourself 


Your design should obey the SRP. but also be PRY 

The SRP is all about responsibility, and which objects in your system do what. 

You want each object that you design to have just one responsibility to 
focus on — and when something about that responsibility changes, you’ll know 
exactly where to look to make those changes in your code. Most importantly 
you’ll avoid what’s called the ripple effect, where one small change to your 
software can cause a ripple of changes throughout your code. 

But there’s a principle that goes hand in hand with SRP, and that’s DRY: 


nm\ 


Don’t repeat yourself 

Avoid duplicate code by abstracting or 
separating out things that are common and 
placing those things in a single location. 


The different Date classes are not DRY 

Each of the different Date classes (FirstDate, SecondDate, ThirdDate) 
have almost identical behavior in their validateEvent () methods. This not 
only breaks the SRP, but means that one change in logic — like specifying that you 
can actually Sleep Over on the second date — would result in changes to the logic< 
in all three classes. 


T^\s cyu'idklY Wv'S a 
州 am 七崎 Wve. 



"These methods 

•deivti 匕 al todt .. 




DRY is about kaving eacn piece of 

information ana tekavior in your 
system in a single, sensible place. 
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good-enough design 


ihereictre no ^ 

Dumb Questions 


SRP sounded a lot like DRY to me. Aren’t both about 
a single class doing the one thing it’s supposed to do? 

They are related, and often appear together. DRY is about 
putting a piece of functionality in a single place, such as a class; 
SRP is about making sure that a class does only one thing, and 
that it does that one thing well. In well-designed applications, 
one class does one thing, and does it well, and no other classes 
share that behavior. 

Isn’t having each class do only one thing kind of 
limiting? 

It's not, when you realize that the one thing a class does 
can be a pretty big thing. For example, the Event class in 
iSwoon and its subclasses only store and manage one thing, the 
details of the specific event. Currently those details are only the 
name of the event, but those classes could store any of a host 
of details about an event, such as times, dates, notifications 
and alarms, even addresses. However all this extra information 
is still only about one thing, describing an event. The different 
Event classes do that one thing, and that’s all they do, so 
they are great examples of the SRP. 


Q/ And using SRP will help my classes stay smaller, 
since they’re only doing one thing, right? 

Actually, the SRP will often make your classes bigger. 
Since you’re not spreading out functionality over a lot of 
classes—which is what many programmers not familiar with the 
SRP will do—you’re often putting more things into a class. 

But using the SRP will usually result in fewer classes, and that 
generally makes your overall application a lot simpler to manage 
and maintain. 

Q；i ’ve heard of something called cohesion that sounds 
a lot like this. Are cohesion and the SRP the same thing? 

Cohesion is actually just another name for the SRP. If 
you’re writing highly cohesive software, then you’re correctly 
applying the SRP. In the current iSwoon design, a Date does 
two things: it creates events and it stores the events that are 
happening on that specific date. When a class is cohesive, it 
has one main job. So in the case of the Date class, it makes 
more sense for the class to focus on storing events, and give up 
the responsibility for actually creating the events. 




ix> khow abou-t desia h 

㈣ ⑽汾 


csigh. 


I r ouVc been loaded up with hints on 
howto make the iSwoon design now 
make sure you've worked through and 
solved the exercise on pages 154 and 
\55 before turning the page... 

as £RP ^ a vcally yrtai 
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refactoring iSwoon^ design 



fLont ExeRclSe 


You were asked to take a look at the current design and mark up what changes you’d 
make to apply the single responsibility principle to the iSwoon design to make it a 
breeze to update your software. 


ihc same Dale 
object is used -Pov- all 

Zhd ; IyA, oy 
之 ⑽， ThcvVc all just 

•^s-tah^cs o+ -this 乙丫 ass. 



TV Pa*tc dlass y\o^i -follows i\\t SRP 

s'mtc *i*t k\r\ov/s only "to 

doy\*tam d ⑽ mbcV" of CVCr\*U> 
y/V^a*t date r\umbcv- »*t »s (Ut 2-v\d, 

{ird e*U ). 


A da*tc cmly y^ccds -to 
ky\o>w 4a 七 wuwkcv- i*t 
*,S. I 七 ‘dies addmj 

Evcyrt uses \oyt 

-f\row i\\t Evcvrt t\ass) } 

a 灼 dl oy\ 3 date. 


_Pate 

CTda-bcKu^bcv* 七 

r-i+ addEvc^-tO Wean 

C + ^Pa-teO Wean 





cvcir\*t is added ； *tV^c date 
tails tV^c event’s datcSu^ortcdf ) 
m Aod y/»^ »ts date ^mber s« *»+ 
七 he eve 灼七 is allov/cd- So deal” 

*tV^ cvcr\*U is lc*f*t VAf "to "tV^C tvcr\*b 
tlass—-t^aVs jood SRP tV^cv-c. 


洲祕 tlums^ mV^rtaf ’S 
… lo^ needed, r.oYi 

a pate Uovis ^at 

,s... more MPaic, 

Sc^dPatc Masses. 
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good-enough design 


cvcht keeps up with 
which dates it ; s allowed o 


TV^ dcs^iptio^ tV^c c^v\i 
is y\ov/ oy\C i*ts 
raider bemj fart d 七心 

dass drf ’m’rbo 灼. 


A daic still is 
V"da-tcd -to cvchts 




Eveh*t(allowcdDa*tcs : 'Ml, dcsthp-tioh : SVm^) 

+ da-tcSuppo\rtcd(da*tc/Vo : mi) ：booledh 


TWis is a tor\s*t\ru^*tov- 3r\d is “lied 

a 灼 cvcir\*t »s heated. A^y 

cve^-t ms-ta^c K^ccds -to know *Uo 
七 Wy: y/V^a-t da 七 es i*t is allowed ov\ 

a^d y/V^at its dcst\r*i\>tioh IS. 



This |士 dates -Pmd ou-t i-f -this 
cveivt is allowed, li takes -the dale 
humbeir, ahd hahdlcs all -the 
itself Uo^t gRp ih adtioh, 
alohg with a little DRY), 



Same as dates ： a^y number c^f 
di 以饮⑼七 cvc\r\*t *ms*ta^cs C9y\ 
y\o^i be dc-f med 3^d 9ddcd 
AT RUNTIME! 


No r\ttA -fov lo*ts of subclasses -fo\r 
cadh type o-P cvc^*t; oy\c dlass 
灼 ow do 七 he job -fov cvcv-y -type o-f 
ev 伙七 . Eadh eve 灼七 -type is jus 七扣 
'ms*ta^^c of *thc Evc^i dldss. 
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standup meeting 


The post-refactoriwg standup meeting 


So, ifs halfway through 
Week 3, how are we doing? 


Bob: Got it all done, we now have a really flexible piece 
of software that can support any number of different types 
of dates and events. 

Laura: That’s great! Sounds like the extra work might 
pay off for us; we’ve got a ton of new events to add... 

Bob: Oh, it will. Now we can just write one or two lines 
of code, and, boom, the new event is in the system. We 
allowed between two and five days for each event, and 
now it only takes a day, at most. 

Mark: You’re not kidding. I’ve already added all the 
new events. And I’m sure we could make some more 
improvements as well... 

Laura: Wait, just hang on a sec. For now the software is 
more than good enough, actually. Let’s not starting making 
more changes just because we can. 



Mark: So what’s next? 


Bob: Well, now that I’ve got the refactoring done, it looks 
like we have some time to focus on the demo that the 
Starbuzz CEO wanted... 


- iJiereictre no ^ 

Dumb Questi9ns 

When Laura says that the code is 
good enough, what does she mean? 

Good question! We'll talk a lot more 
about testing in Chapters 7 and 8 and how 
you can be confident, and prove that your 
code does what it should. 
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good-enough design 


rtcvc avc ovi^mal 
tasks ^o» 

>youv boav-d* 




Task 7 


Cvc3*tc Send Flo>wcv-s I 

event dor>*tams 

i\\t address and 


I -flower ovdev- 

z 1 


Task 10 

Cv-catc a ''Book 
iRcs-tauvah-t w event 
klass 



Thanks io youir h ew d« 咖， 

f dd 79 dh ，七 ^Sjusi OhC ov^ 
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tasks have bcch dohe i h ohc day 
^stcad o4 - seveh/ 
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Wvth a w de 呼 ’ 
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Pays Ic-f-t 


A great design kelps you te more 

PRODUCTIVE as well as making 

your software more FLEXIBLE^ 
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unplanned work 


Unplanned tasks are still just tasks 

The Starbuzz CEO’s demo is an unplanned task, but you deal with it just like 
all the other tasks on your board. You estimate it, move it to the In Progress 
section of your board, and then go to work. 



Unplanned tasks on the board become planned. 


It doesn’t matter kow 


An unplanned task may start out differently, but once it goes on 
your board, it’s treated just like all your planned tasks. In fact, as 
soon as you assign the task and give it an estimate, it really isn’t 
unplanned anymore. It’s just another task that has to be handled, 
along with everything else in your project. 


And that’s how you handle a task that starts out unplanned from 
its inception to completion: just like any other task. You estimate 
it, move it to the In Progress section of your board, and work it 
until it’s done. Then you move it into the Completed section and 
move on. 


a task starts out. Once 
it’s on your toard, it’s 
got to te assigneJ, 
estimateJ. and worked 
on until it’s complete. 
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good-enough design 


Part of your task is the demo itself 

In addition to the time you’d spend working on the demo, you’ve got 
to think about time spent actually doing the demo. If you and your 
lead web programmer both spend a day traveling to Starbuzz and 
showing off iSwoon, that’s got to be part of your task estimate. 



Your estimates skould te complete 


When you’re estimating your tasks, you should come up with the time it 
takes to complete the task — and sometimes that involves more than just 
code. If you’ve got to demo the code or meet with a stakeholder, include 
time for those activities, too. 


Task ZO <Y0U> 

Add {i o\rdc\r 
cvch*t flind sehd ov-dev* 
by email -fco S*tcl\rbi 


)UZZ. 


5 




*^o dhd 


o 



Nice...can you email me the minimum system 
requirements? And does it work on Safari and 
Firefox, too? I want to start spreading the 
word to our customers right away. 


Look’ A/)o\rc 

uhplahhcd -tasks. 



CtO, ^ a 
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good-enough delivers 


Fireside Chats 



Tonight’s talk： A sit-down discussion between 
Perfect Design and “Good Enough” Design. 


“Good Enough” Design Perfect Design: 

Hi! So you’re a Perfect Design? Man, I’ve always 
dreamed about meeting you! 

Thanks. Designs like me are pretty rare. In fact I may 
be the only one you’ll ever meet. 

Why’s that? 

Well, the problem is that it’s really hard to come up with 
a design that everyone thinks is perfect. There’s always 
somebody out to get me with their criticisms. And with 
refactoring, I keep getting changed. But you’re pretty 
valuable yourself, you know... 

Yeah, I suppose so. As long as I help everyone be 
productive and meet their deadlines, and the customer 
is getting the software they need, then I’m doing my job. 

You see, that’s the thing. People spend so much time 
on me that they never meet their deadlines, they never 
deliver software, and they never get paid. That can 
make me pretty unpopular. It kind of sucks, really. 

Huh, I never thought of it like that. I thought when you 
came along everyone would be all hugs and kisses... 

Not at all. Usually by the time I show up, the team is 
running late and I can’t help out anywhere near as 
much as as they thought. And then there’s always the 
danger that I’m not completely perfect... 

What do you mean? After all that hard work your team 
might still be able to make you even more, err...perfect? 

Unfortunately, yes. You see, perfection is a bit of a 
moving target. Sometimes, I just wish I could be like 
you and actually deliver. Maybe not great, but — 
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good-enough design 


“Good Enough” Design: 

Hey, wait a second. That sounded pretty condescending. 


Yeah, I suppose everyone is pretty stoked when I help 
them get great software out of the door. But I always 
figured that I was second class somehow and that they 
loved you... 


So really what you’re saying is that you’d like to be a 
design for software that actually got delivered? 


So, I guess I’m good enough to get the job done, to 
meet the customer’s needs, and to be easy enough to 
work with that my developers can develop code on time. 
That’s what really matters. 


Perfect Design: 


Well, sure. Everyone ships you out because you draw 
a line in the sand and say you’re finished when the 
customer gets what they want. So even though you’re 
not perfect you deliver. And a developer who delivers 
great software, whether it’s designed perfectly or not, is 
a happy developer. 


If by love, you mean “never have time for,” then you’re 
right. 


Exactly! I aspire to be you, in many respects. People 
want to meet their deadlines and to ship software that 
the customer will sign off on. That’s not settling; that’s 
just being good developers and getting paid. You know 
developers, right, those guys that get paid for delivering? 
Well, I’m not in their good graces when they’ve come 
up with me and no software to actually ship... 


Yep, don’t ever put yourself down. In this world it’s nice 
to be perfect, but it’s better to be ready and shipping. 
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end of iteration board 


Whew Gvcrythlwg's complete, the iteration's done 

Once you finish all your tasks, including any unplanned demos for 
forward-looking coffee addicts, you should end up with all your user 
stories, and the tasks that make them up, in your completed area of 
the board. And when you’ve got that, you’re finished! There’s nothing 
magical about it: when the work is done, so is your iteration. 


User s-borics 


\y\ ?royctss 


You Completed all 

these usev- s-fcov-ics. 






170 Chapter 5 












































good-enough design 
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Title: 


Title: 


Create a date 
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exercises 


% + 

_+ 分 m 秦 1 峰 V — 

• ♦ 

Take each of the following techniques and artifacts from this chapter 
and match it to what it does. 


Unplcinned 伽 ks and user st9ties 

I help you make sure that everything 
has its place, and that place is only 
one place. 

Perfect design 

With me, the design gets better with 
small improvements throughout your 
code. 

SHF 

I make sure that the unexpected 
becomes the expected and managed. 

Ilefect9ring 

My mantra is, “Perfect is great, but I 
deliver.” 

DR/ 

I make sure that all the parts of your 
software have one well-defined j ob. 

Good-enough design 

I’m what you strive for, but ultimately 
you might not deliver. 
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good-enough design 



Software Development Design Cross 

Let’s put what you’ve learned to use and stretch out your left brain a bit! 
All of the words below are somewhere in this chapter. Good luck! 



Across 

1. Great developers. 

3. When an unplanned task is finished it is moved into the. 

column. 

4. Your burn down rate should show.the work on your 

board, including any new unplanned tasks. 

6. When a task is finished it goes in the.column. 

7. An unplanned user story and its tasks are moved into 

the.bin on your project board when they are all finished. 

9. If you find you are cutting and pasting large blocks of your 
design and code then there's a good chance that you're 

breaking the.principle. 

12.is the only constant in software development. 

13. When a design helps you meet your deadlines, it is said to 

be a.design. 

14. If a user story is not quite finished at the end of an iteration, 

it is moved to the.bin on your project board. 

15. A good enough design helps you. 


Down 

1 ■ Unplanned tasks are treated the.as unplanned tasks 

once they are on your board. 

2. When you improve a design to make it more flexible and 
easier to maintain you are.the design. 

5. You should always be.with your customer. 

6. When all the tasks in a user story are finished, the user story 

is transferred to the.bin 

8. Striving for a.design can mean that you never actually 

cut any code. 

10. When a class does one job and it's the only class that does 

that job it is said to obey the .responsibility principle. 

11. An unplanned task is going to happen in your current 

iteration once you have added it to your. 
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exercise solutions 


% + 

_ + 費腎备餐擊，- 

Take each of the following techniques and artifacts from this chapter 
and match it to what it does. 


Unplcinned 伽 ks and user stales 


Perfect design 




Ilefoct9ring 


Di^/ 


Good-enough design 



I help you make sure that everything 
has its place, and that place is only 
one place. 

With me, the design gets better with 
small improvements throughout your 
code. 

I make sure that the unexpected 
becomes the expected and managed. 


My mantra is, “Perfect is great, but I 
deliver.” 


I make sure that all the parts of your 
software have one well-defined job. 


I’m what you strive for, but ultimately 
you might not deliver. 
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good-enough design 



Software Development Design 
Cross Solution 
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6 Version control 




、 Defensive development 







Alright guys, listen up. Bob’s 
writing new code. Youve got to 
keep him safe, no matter what 
happens, understand? 


When it comes to writing great software, Safety First! 

Writing great software isn’t easy … especially when you’ve got to make sure your code 
works, and make sure it keeps working. All it takes is one typo, one bad decision 
from a co-worker, one crashed hard drive, and suddenly all your work goes down the 
drain. But with version control, you can make sure your code is always safe in a 
code repository, you can undo mistakes, and you can make bug fixes — to new and 
old versions of your software. 


this is a new chapter 
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introducing beatbox pro 


YouVg got a new contract 一 PeatPox Pro 


Congratulations — you’ve been getting rave reviews from iSwoon, and you’ve landed a new contract. 
You’ve been hired to add two new features to the legendary Head First Java BeatBox project. BeatBox 
is a multi-player drum machine that lets you send messages and drum loops to other users over the 
network. 


Like every other software development project out there, the customer wants things done as soon as 
possible. They even let you bring along Bob, one of your junior developers, to help out. Since the 
stories aren’t big enough to have more than one person work on them at a time, you’ll work on one 
and Bob will work on the other. Here are the user stories for the new features you’ve got to add: 


Title 


SewdaPoketo 

other users 

Description : 识血 

_ 微询， . . ^ 

— 0 一 •• 


* t,e: Send a picture to 

otherusers 

^ar eM osi ze « 


n 


Hority: 


s 


Estimate: 


0 




basics asso^aU^ 


Bob wi 


'oi»» 


vi,1 pull iasks 
"this 


Dium 

H 4 I 4 . 

OpeimHa 

助 am 
Drash Cfmb^rl 
HandCHfr 
Hlpfi i<m 

war 抑 

IcwCwQai 

lAbrisftw 
|dw miri fchin 
JH 聊 Aa 。。。 

■Own wOofiaa 



^3 po,V,£ 


乙扣 dovmload 七 he Code 七 ha 七 v/cVc v/i*th : / / v/y/y/ hccld-fiv-s*tlclbs.6om/books/h-fsd/ 
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Stickies 

Task y 1 ^BKte 

Let’s get right to the new features. Here’s a snippet from the 
BeatBox client code. Your job is to map the task stickies to the 
code that implements each part of the "Send a Poke...” story. We’ll 
get to the GUI work in a minute. 


version control 


Task I 


MVB 


II 


more 


BeatBox.java code above this 


public class RemoteReader implements Runnable { 
boolean[] checkboxState = null; 

String nameToShow = null; 

Object obj = null; 

public void run() { 

while ((obj 二 in.readObject()) != null) { 

System.out.println("got an object from server ”）； 
System.out.printIn(obj.getClass ())； 

String nameToShow = (String) obj; . 

checkboxState = (boolean[]) in.readObject(), 

if (nameToShow.equals(POKE_START_SEQUENCE)) { 

playPoke (); . ，， 

nameToShow = "Hey I Pay attention. M ; 

otherSeqsMap.put(nameToShow, checkboxState); 
listVector.add(nameToShow); 

incomingList.setListData(listVector ), 

} // close while 

} catch (Exception ex) { ex.printStackTrace(), } 

} // close run 

private void playPoke () { 

Toolkit .getDefaultToolkit() .beep ()； 

} // close inner class 


£ouy>d audible alert 
\n\\tr\ v-cdcivmj d fokc 
message (da 灼’七 be 


Task Z UU 61 

Add suppov-i -fov 
dKcdk'mg -Pov iKc Poke 


dm 


cssage. 


Task^V 

Poke visual 
alcrb ^cssa^c 

s—cw. 


WP 


0 


IVB 


Implement VCdcivcv 
Code b> vead the 
o( ttc 
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digging into code 



Stickies 

Task ^^B^s Solution 


We’re not in Head First Java anymore; let’s get right to the new features. 
Here's a snippet from the BeatBox client code. Your job was to map the task 
magnets to the code that implements each part of the "Send a Poke..." story. 

h \\ ^oes ^ 


s Code 

that Will vuh ih the 

w Bca-tBox. - 


II ... more BeatBox.java code above this 

pubUc class RemoteReader ^ple.ents ^nnable 
boolean[] checkboxState = mill ， 

String nameToShow = null ； 

Object obj = null; 


• ^ 6 ' a r S 


Task 3 MVB 

|mplcmCh*t VCdcivcv 
Code to read tiic 
o(( o( the 


STA f T — S _"C£: 

^ poke sou，d 

1 响卜 he 
W，ih oulr i cx i 3 


public void, run () { 

(o bj1 n-a S 3ectO ◦ 二) 二 se— ，， ) 

f/:: 二 

if (nameToShow. equals (POKE_START_SEQUENCE)) { 

ntmSoShow = "Hey! Pay attention ."； 


； 

otherSeqsMap.put(nameToShow, checkboxState) 
listVector.add(nameToShow ; 

IncomingList.setListDatadistVecto , 

// close while 、 （ ex>printstackT race ()； 


// 


catch (Exception ex) 
close run 


Wcirc s ouir hCw 

pl^yPokcO I^cihod I 

beeps d 

how - ^ you Wdh-t a H 

^lle^c, add 

pokc-souhd suppo^-tj 


private void playPokeO - 

Toolkit.getDefaultToolk: 

II close inner class 


Task I MVB 

Sou 灼 d a 於 audible alert 
y/hen \rc6civm5 d fokc 
message Ua^i be 
a^^oym^P 
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:一 vt v-cads 

sewer- 


Task Z UA6{ 

Add suppov-i -fov 
^Kcdk'mg -Pov iKc Poke 

9 message- 
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Task ^ ^ 

Mc^ry Poke v\sual 
alert •，山 wcssa ^ c 
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version control 


thereicire no o 

Dumb Questi9ns 


This isn’t a Java programming 
book. Why are we wasting time looking 
through all this code? 

Software development techniques 
cover everything related to a project, from 
organization and estimation down through 
code. Earlier, we talked about the planning 
and execution parts of a project, and then 
we got a little closer to code and talked 
about design. Now, we need to dive all the 
way down and talk about some tools and 
techniques you can use on your code 
itself. Software development isn’t just about 
prioritization and estimation; you’ve still got 
to write good, working, reliable code. 

I don’t develop in Java. I’m not 
sure what some of the code in there does. 
What do I do? 

That’s OK. Do your best to understand 
what the code is doing, and don’t worry 
about all the Java-specific details. The main 
thing is to get an idea of how to handle 
and think about code in a solid software 
development process. The tools and 
techniques we’ll talk about should make 
sense whether you know what a Java thread 
is or not. 


I think I must have...misplaced... 
my copy of Head First Java. What’s this 
whole BeatBox thing about? 

BeatBox is a program first discussed 
in Head First Java. It has a backend 
MusicServer and a Java Swing- 
based client piece (that’s Java’s graphical 
toolkit API). The client piece uses the Java 
Sound API to generate sound sequences 
that you can control with the checkboxes 
on the form’s main page. When you enter a 
message and click “sendit,” your message 
and your BeatBox settings are sent to any 
other copies of BeatBox connected to your 
MusicServer. If you click on the 
received message, then you can hear the 
new sequence that was just sent. 

Q/ So what’s the deal with that 
POKE_START_SEQUENCE thing? 

Our story requires us to send a poke 
message to the other BeatBoxes connected 
to the MusicServer. Normally when 
a message gets sent it's just a string that is 
displayed to the user. We added the Poke 
functionality on top of the original BeatBox 
by coming up with a unique string of 
characters that no one should ever type 


on purpose. We can use that to notify the 
other BeatBoxes that a “poke” was sent. 

This sequence is stored in the POKE_ 
START_SEQUENCE constant (the actual 
string value is in the BeatBox. j ava 
file in the code you can download from http:// 
www.headfirstlabs. com/books/hfsd/). 

When other BeatBox instances see the 
POKE—START—SEQUENCE come 
through, they replace it with our visual alert 
message, and the receiving user never 
actually sees that code sequence. 

Q/ What’s all this threading and 
Runnable stuff about? 

BeatBox is always trying to grab data 
from the network so it can display incoming 
messages. However, if there's nothing 
available on the network, it could get stuck 
waiting for data. This means the screen 
wouldn’t redraw and users couldn’t type in a 
new message to send. In order to split those 
two things apart, BeatBox uses threads. 

It creates a thread to handle the network 
access, and then uses the main thread to 
handle the GUI work. The Runnable 
interface is Java’s way of wrapping up some 
code that should be run in another thread. 
The code you just looked at, in the last 
exercise, is the network code. 


- 

Bob’s making good progress on his end, too. Can you think of 
anything else you should be worrying about at this point? 
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finish the story 


Awd wow the frUl work 


We need one more piece of code to get this story together. We need to add a 
button to the GUI that lets the user actually send the Poke. Here’s the code to take 
care of that task: 


// The code below goes in BeatBox.java, 

// in the buildGUI() method 

JButton sendlt = new JButton( M sendlt M ); 
sendlt.addActionListener(new MySendListener()); 
buttonBox.add(sendlt); 


Task? 


< 


You 


> 


Add bu*t*tov\ *to 6{\A\ 

bo schd Poke 
bo o*tKcv* BeatBox 




JButton sendPoke = new JButton("Send Poke"); 
sendPoke.addActionListener(new MyPokeListener()); 
buttonBox.add(sendPoke); 


〆 L ee.A^CP 6vcatc a W 



wc set up a 

lis-tchcv SO wc read 

wheh it’s disked. 

userMessage = new JTextField(); add butfem loo% 

buttonBox . add (userMessage) ; iiold'mj o*tW\r loutto 吣 . 


// Below is new code we need to add, also to BeatBox.java 

public class MyPokeListener implements ActionListener { 


public void actionPerformed(ActionEvent a) { 
// We'11 create an empty state array here 
boolean[] checkboxState = new boolean [255] 


try 


ttcv-c v/c dv-catc by\ av-v-ay o( 
booled 灼 s -Pov- ouv- s-ta-tc- Wc 乙 a 灼 

leave them all -false because -the 
v-cdcivmj side i^ov-cs -therw 
it jrts 七 he POi^B 6o_and. 


out.writeObject(POKE_START_SEQUENCE); 
out.writeObject(checkboxState); 
catch (Exception ex) { 

System.out.printIn("Failed to poke! n ) 



fcoolca^s {p^ 0 ^cv a 弋 
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s ou^* 

^°^Rece',ve\r 
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HtsfiT^m 

HNUpi^ 
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#NfN 
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L 9 w^rNr_ 



nKC^ngi 


Excellent! Your changes work as advertised. We’ll 
copy the code up to the demo server, and all that’s left 
is for Bob to merge his stuff in. Time to call it a night. 


File Edit Window Help Ouch 



o Now send off a Poke by clicking the “Send Poke 
we named PokeSender. 


55 


And a quick test... 

Now that both the client and server are implemented it’s time to make sure 
things work. No software can go out without testing so... 

o First compile and start up the MusicServer. 




o 


Then start the new BeatBox 
we can test the Poke. 


-we’ll need two instances running so 


V»\\ V»sW W 

— a W 

七 —c vt 


use d4W 於七 ^ames 
we kv\o>M y/WiA is y/WaW 



Wcv-c s ou\r hew 

队 bu 仏 h . 







\o^ v | , . 




j\>Y\A S 


\\V.t 办 


button on the instance 







Hey! Pay attenti 

I 

on. 


S OVaV 


^ssay 
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File Edit Window Help Buildin’ 


.chapter6.BeatBox PokeSender 


bin headfirst. 


.chapter6.BeatBox PokeReceiver 


bin headfirst. 


hfsd> java 


hfsd> 


hfsd> mkdir bin 

hfsd> javac -d bin src\headfirst\sd\chapter6\*.java 
hfsd> java -cp bin headfirst.sd.chapter6.MusicServer 


aooQoonaopoaaaon 

□□□□□□□□□□□□□□□o 

□ □□□□□□□□□□□□□□a 

□ □□□□□□□□□□□□□□□ 
□□□□□□□□□□□□□□□o 
□□□□□□□□□□□□□□aa 
□□□□□□□□□□□□□□□a 

□□DDODDGaDDOQDDG 

□ □□□□□□.□□□□□□□□o 

□ □□□□□□□□□□□□□□G 
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merging changes 



ncv-c^s Bob’s ve\rsioh o*f 
Bc3*tBox 一 the SchdPi^tuvc 

button is irwpIcrwCh'tcd- 




And Pob does the same... 

Bob finished up the tasks related to his story and ran a quick test on his end. His task 
is working, so he copies his code up to the server. In order to do the final build he 
merges his code in with ours, gets everything to compile, and retests sending a picture. 
Everything looks good. Tomorrow’s demo is going to rock... 






^ no o 

Questi9ns 

Why did we make the bin directory before we 
compiled the code? 

We’ll talk more about this in the next chapter, but in 
general it’s a good idea to keep your compiled code separate 
from the source. It makes it a lot simpler to clean up and rebuild 
when you make changes. There's nothing special about the 
name “bin ”； it’s just convention and is short for “binaries” 一 i.e., 
compiled code. 





Wait, did Bob just merge code on the demo server? 

Yup … 



meni sender 
Poke button 


[L 



i 

d 


D 


tJierei 

>umb 1 


I 


I’m not familiar with networking code. What’s 
happening in that code we just added? 

On the sending side we represent the sequence settings 
as an array of checkboxes. We don’t really care what they're set 
to, since we won’t use them on the receiving side. We still need 
to send something, though, so the existing code works. We use 
Java’s object serialization to stream the array of checkboxes 
and our secret message that triggers the alert on the other side. 

On the receiving side we pull off the secret sequence and the 
array of checkboxes. All of the serialization and deserialization 
is handled by Java. 
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CaasW 伏 . 



Tm not hearing any alert. 

And whafs SECRET—POKE— 
SEQUENCE? I*m not impressed. 


l?emo the new PeatPox for the customer 

We’re all set to go. Your code is written, tested, and copied up to 
the demo server. Bob did the final build, so we call the customer 
and prepare to amaze the crowds. 


me ri^tuv-c 
is Bobs Code 






恤 f 、 抑 d . 
㈣ OVX . 



So what went wrong? 

Our code worked just a few pages ago. So what 
went wrong? More importantly, what would 
you do differently in the future to make sure 
nothing like this ever happens again? 
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□000 

□ □□□ 
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□□□a 
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oaoQ 

□ □□□ 

DOOD 

□□□ o 

□ □□□ 

□ □□□ 
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□■oao 

□□ □ o 

□ □□□ 

□ □ □ □ 
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disaster recovery 






Something’s clearly gone wrong. Below is some code we compiled on our machine 
and the same section of code from the demo machine. See if you can figure out what 

happipid. 


: lass R — — 

二』二=二一 ， 

string nameTobnow 

Object ob： = null； 




I eves todt W 

l u r watWmc— w>vked 
■W n^c v-av^ >t- 


in readObject0) ! 

System, out.printlnl^ot an 


try 1 

while!(obj 


public void run() 

=null)( ”、. 

object from server ) ， 

- t orl ntln(obj.getClassO)； 

Sr / 二二 -w = 

checkboxState (b °° G ( p 0KE STA rt—SEQUENCE) ) { 

if (nameToShow.equals(PO _ 一 

playPokeO p attention."； 

nameToShow = Hey ' 


汽〜 s {^ c 
o, i hc A ^ o 


iiSS 科 ) 

// close 油 lle — 、 ； ex .print 


} catch (Exception ex) 
// close run 


null ； 


It Cl rf S Rem ° teReader implement 
boolean[J checkboxState = null- 

String nameToShow 
Object obj = null ； 


public void run() 
try { 

while ( (obj = i 


s Runnable 


null) 


n •readObject() 

System.out.println ("got an obi^nt- ^ 

s S f St ⑽灿 (obVgetClass O)^ 

String nameToShow = (StrincM 
checkboxState = (booleantj? 


if (nameToSho 


w 


receiveJPEG() 


obj ； 

in•readObject ()； 

• e^als (PICTURE—START—SEQUENC^) 


else { 

listVp S r MaP ； PUt (nameToSho ^^ checkboxState) - 
■istVector.add(nameToShow )； ' 

} lnC ° mingList * se tLi s tData(listVector )； 

} // close while 
catch (Exception ex) { 

sx.printSta.ckTira.ce ()； 


close 


run 
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Standup meeting 


version control 





Mark: Wow. Bob really blew it with that demo. 

Bob: What are you talking about? My code worked! 

Laura: But you broke the other story we were trying to demo! It 
worked fine before you got to it. 

Bob: Wait a minute — why am I getting blamed for this? You asked me 
to copy my code up to the demo server so we could build it. When I did 
that, I saw you guys had changed a lot of the same stuff. It was a mess. 

Mark: So you just overwrote it?? 

Bob: No way — I spent a bunch of time comparing the files trying to 
figure out what you had changed and what I had changed. To make 
things worse, you guys had some variables renamed in your code so I 
had to sort that out, too. I got the button stuff right, but I guess I missed 
something in the receiver code. 


Laura: So do we still have the working Poke code on there? 

Bob: I doubt it. I copied my stuff up with a new name and merged 
them into the files you had up there. I didn’t think to snag a copy of 
your stuff. 


Mark: Not good. I probably have a copy on my machine, but I don’t 
know if it’s the latest. Laura, do you have it? 

Laura: I might, but I’ve started working on new stuff, so I’ll have to 
try and back all my changes out. We really need to find a better way to 
handle this stuff. This is costing us a ton of time to sort out and we’re 
probably adding bugs left and right... 



Not "to rwChtioh y/cVc 

the w\roy>^ way oy \ ouv~ 
dowh \rol-tc 


buVh— 
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version control in action 


Lcfs start with 
VERSION CONTROL 




Keeping track of source code (or any kind of files for that matter) 
across a project is tricky. You have lots of people working on 
files — sometimes the same ones, sometimes different. Any serious 
software project needs version control, which is also often called 

configuration management, or CM for short. 

Version control is a tool (usually a piece of software) that will keep 
track of changes to your files and help you coordinate different 
developers working on different parts of your system at the same 
time. Here’s the rundown on how version control works: 

o Bob checks out BeatBox.java 
from the server. 


O' 

weaves ^OU 


❽ 




Bob makes some 
changes to the code and 
tests them. 



y 七 a 

\y/Ovk OV\- 



Thc veirsioh toy^br 0 \ 

'r ks U P ^ 

Systam.out.printlnrui don*!"); I Cm ^ 

to the developer. 

Found it\ here ya go … ^ 


The rest of your team can check 
out Version 1 of BeatBox.java 
while Bob works on his version. 


a a 

s^\\t YiW.U ^ks 

w»s Aa 呼 S O 於 w’s 

loddl 








it 




把2°二 



TV " SC : 二工 

Mtrs\ov\ co^xro* 
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version control 



Bob checks in his changes. 



\ toAt katk 


Q 








After Bob checks in his changes, the team 
can get an update from the server with 
the new code. 




go... 



theve^cive no o 

Dumb Questi9ns 



Sow sys-tcr^s 
PV-CVCh-t othcm people 
W r ， odi^y ih3 i hc 
.扑 thais bcihg 
edited by sorvteohe ； 
Wile dhev systems 
hhdle r^cirjihj -fchc 


So if version control is a piece of 
software, which version control product 
should I use? 

There are lots of choices out there for 
version control tools, both commercial and 
open source. One of the most popular open 
source ones is called Subversion, and that’s 
the one we’ll use in this chapter. Microsoft 
tools such as Visual Studio like to work 


with Microsoft’s version control tool, called 
Visual SourceSafe, or Microsoft’s new Team 
Foundation product. 

Version control tools all do pretty much the 
same thing, but some offer different ways 
to do it. For example, some commercial 
systems have strict access control on 
where you can commit code so that your 
organization can control what goes into what 
build. Other tools show you the different 
versions of files as virtual directories. 


You’re only showing one file and 
two developers. I’m guessing it can do 
more than that, right? 

You bet. In fact, a good version control 
tool is really the only way you can scale 
a team. We'll need some of those more 
sophisticated features (like merging changes, 
tagging versions, etc.) in just a minute... 
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creating a repository 


First set up your project. 



WcVc assurw'mj you^vc youir vcv-sio^ 
do^tv-ol so^-twavc ms 七 ailed. If hot, you da 外 
download it -fv-om -the Subvc\rsior> v/eb site. 


The first step in using a version control tool is to put 
your code in the repository; that’s where your code is 
stored. There’s nothing tricky about putting your code in 
the repository, just get the original files organized on your 
machine and create the project in the repository: 


o 


First create the repository~you 
only need to do this once for 
each version control install. 
After that you just add projects 
to the same repository. 


File Edit Window Help TakeBacks 


hfsd> svnadmin create c:\Users\Developer\Desktop\SVNRepo 
hfsd> 




This tells £ubveirsioh -fco 
3 hew v-eposi-fcovy... 


tWis d'ivcttov- 7 - 


o 


Were r 


Next you need to import your code into the 
repository. Just go to the directory above 
your code and tell your version control 
server to import it. So, for your BeatBox 
project, you’d go to the directory that 
contains your beat box code. If you’re using 
the downloaded files, that directory is called 
Chapter 6: 

TW, S * 1S 代 — W/ you 

tc\\ ^ crs '° m s 七找 I. 〜 lA/mdov/s you II ^ 









I 




Ac- 


m step I • C 

use -fov-Y/av- 


d sldsV\ y\0"t3 七 io 灼 . 



File Edit V'.ndow Heiv^Tariffs 


hfsd> svn 


rteves Aat 
td *to be 

ia^ovc 


?\roj 

tailed —* 


SVNRepo/ 

Adding 

Adding 

Adding 

Adding 

Adding 

Adding 


ort Chapter6 file : ///c : /Us6rs/Developer/Desktop/ 
BeatBox/trunk -m ^Initial Imp ort" - 




Chapter6\src 

Chapter6\src\headfirst 

Chapter6\src\headfirst\sd 

Chapter6\src\headfirst\sd\chapter6 

Chapter6\src\headfirst\sd\chapter6\BeatBox.java 

Chapter6\src\headfirst\sd\chapter6\MusicServer.java 


Committed revision 1. 


hfsd> 


来 You da 的 七 he -full Subvcvsioh dodur»\C^*ta*tioir\ hc\rc ： / sv^book ved—bca^ dom/ 


TVis is jus 七 

des 乙 \ribm5 

y/V^a-t wcVc 
do'mji wc II 
talk mov-c 
dbou 七 *bWis 
la-tcv-, -too- 


Subvcirsioh 
3 dds ca^h 

' h "to youv- 

MposiWy *f 0 浐 

BcaiBox 


s 
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version control 


...then you caw check code m and out. 


Now that your code is in the repository, you can check it out, make your changes, and check 
your updated code back in. A version control system will keep track of your original code, all 
of the changes you make, and also handle sharing your changes with the rest of your team. 

First, check out your code (normally your repository wouldn’t be on your local machine): 

TWis tclU Subversion -to eMtcV This pulls Code the BcatBox 
o To check out your code, 山叫 7 encode. / ^posi a，d puts it 

you just tell your version 


control software what 
project you want to 
check out, and where 
to put the files you 
requested. 

Subvc^rsioh pulls y ow 
ba^k ou-t ot *tl 
^posiUy Copies 

ah cxisii 


File Edit Window Help Gin 



— “y U d l：；X 


ih 



hfsd> svn checkout file: ///c:/Users/Developer/Desktop/SVNRepo / 
BeatBox/ trunk /peatBox^ 

A BeatBox\src 
A BeatBox\src\headfirs t 

A BeatBox\src\headfirs t\sd 

A BeatBox\src\headfirst\sd\chapter6 
A BeatBox\src\headfirst\sd\chapter6\BeatBox.java 
A BeatBox\src\headfirst\sd\chapter6\MusicServer.java 

Checked out revision 1. 

hfsd> 


❻ Now you can make changes to the code 

just like you normally would. You just work 
directly on the files you checked out from your 
version control system, compile, and save. 


❺ 


Then you commit 
your changes back into 
the repository with a 
message describing what 
changes you’ve made. 


Smde you ov\\y -file ； 

'tiid'ts dll tha 七 subvcv-sioh swt 
■to -the mcposiWy—a^d Y\ohu 〆 
r>ow you have d rtew 
me vision 灼 unr»bcv~. 


This -tells Subvc\rs"io\r\ *to Co\ 
dV^a^CS ； *rt will out Y\\ts 

you vc 



\/ou 6 av\ vc - ewe 扒七七卜 【okc 
s^oyrv, smdc Bob Woke 
jfcaWc ^ todt 

七 k Scv^d P'^Wc 


This is a ho\rmal java -file. 
Subvc\rsioh doesh't i-t \v\ 

Ay way”.i 七 ’s still jus 七 todc. 


File Look What IDid 



k a message, y/V>at you d«d- 


hfsd> svn commit -m ''Added POKE support •〃 

Sending src\headfirst\sd\chapter6\BeatBox.java 

Transmitting file data . 

Committed revisior^^^ 


hfsd> 
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merging changes 


Most version control tools will try 
and solve problems for you 


Suppose you had a version control system in place before the great BeatBox debacle 
of ’08. You’d check in your code (with commit) to implement Send Poke, and then 


Bob would change his code, and try to commit his work on Send Picture: 

M tries to check w his code... 





••• 


but quickly runs into a problem. 




3oV>’ s toAt 






public class RemoteReader implements Runnable 
boolean[] checkboxState = null; 

String nameToShow = null; 

Object obj = null; 

public void run() { 

try { 

while ( (obj = in.readObject()) != null) { 

System.out.printIn("got an object from server") 
System.out.println(obj.getClass()); 

String nameToShow = (String) obj; 
checkboxState = (boolean[]) in.readObj ect(); 
if (nameToShow. equals (PICTURE 一 START—SEQUENCE) ) { 

receive JPEG (); 

else { 

otherSeqsMap.put (nameToShow^ checkboxState); 
listVector. add (nameToShow); 
incomingList.setListData(listVector); 

// now reset the sequence to be this 

} // close while 

} catch (Exception ex) { 
ex.printStackTrace(); 


// close run 
// close inner class 



4 yot 

l 


public class RemoteReader implements Runnable { 
boolean[] checkboxState = null; 

String nameToShow = null; 

Obj ect obj = null; 

public void run () { 

try { 

while((obj=in.readObject()) != null) { 

System.out.println("got an object from server"); 
System.out.println(obj.getClass()); 

String nameToShow = (String) obj; 
checkboxState = (boolean[]) in.readObject(); 
if (nameToShow. equals (POKE_START_SEQUENCE) ) { 

pi ay Poke () / 

nameToShow = "Hey! Pay attention."; 

otherSeqsMap .put (nameToShow^ checkboxState); 
listVector.add(nameToShow) / 
incomingList.setListData(listVector) / 

// close while 

catch (Exception ex) {ex.printStackTrace();} 

// close run 


private void playPoke () { 

Toolkit. getDefaultToolkit () .beep () / 
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version control 


The server tries to MERftE your changes 

If two people make changes to the same file but in different places, 
most version control systems try to merge the changes together. This 
isn’t always what you want, but most of the time it works great. 


NoncoHflictmg code and methods are easy 

In BeatBox . j ava, you added a playPoke () method, so the code 
on the version control server has that method. But Bob’s code has no 
playPoke () method, so there’s a potential problem. 



iieve … Bob v\o 


丁 he vcv-sioh ov\ -the scv-vcv- has 
a playPokcO method^ 



hCV"C … VOv nd^ no 

toAt -fov playPokcO at all¬ 


private void playPoke() { 

Toolkit.getDefaultToolkit().beep() 





ir 


Your version control software will combine files 

In a case like this, your version control server can simply combine 
the two files. In other words, the playPoke () method gets 
combined with nothing in Bob’s file, and you end up with a 
BeatBox . j ava on the server that still retains the playPoke () 
method. So no problems yet... 

Put conflicting code IS a problem 

But what if you have code in the same method that is different? That’s 
exactly the case with Bob’s version of BeatBox . j ava, and the 
version on the server, in the run () method: 


These "two bi-ts o-f todt a\rc -the same 
buKs ⑽七 how -to merge them. 



if (name To Show. equals (PICTURE_START 
recei veJPEG (); 

} else { 

otherSeqsMap.put (nameToShow, checkboxS\ 
listVector.add(nameToShow) / 
incomingList . setListData(listVector); 



if (nameToShow. equals (POKE 一 START 一 SEQUENCE) ) { 

playPoke (); 

nameToShow = "Hey! Pay attention."; 

} 

otherSeqsMap• put (nameToShow, checkboxState )( 
listVector. add (nameToShow) ; ' - -■■ ■ fa 

incomingList.setListData(listVector); 



Bob’s Beal 


.java 



BeatBox.java 
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identifying conflicts 


If your software caw't merge the 
changes, it issues a conflict 


If two people made changes to the same set of lines, there’s no way for a 
version control system to know what to put in the final server copy. When 

this happens, most systems just punt. They’ll kick the file back to the v 

person trying to commit the code and ask them to sort out the problems. 士卜 匕 V^u use 


iirto 


y 财喊洳 d 二厂，， 


public class RemoteReader implements Runnable 
boolean[] checkboxState = null; 

String nameToShow = null; 

Object obj = null; 

public void run() { 


try 


while ((obj = in.readObj ect()) != null) { 

System.out.printIn("got an obj ect from server"); 
System.out.println(obj.getClass()); 

String nameToShow = (String) obj; 
checkboxState = (boolean[] ) in.readObj ect(); 
if (nameToShow. equals (PICTURE 一 START 一 SEQUENCE) ) { 

receiveJPEG (); 

} 

else { 

otherSeqsMap• put (nameToShow, checkboxState); 
listVector. add (nameToShow) / 
incomingList.setListData(listVector); 

// now reset the sequence to be this 


} 

II 


} // close while 

catch (Exception ex) 
ex.printStackTrace () 

close run 

inner class 


…。峰也 c you 


\^o\aY vcV"sioy\ 已。灼七 vol saf*t>w3V"C doCsr\ kir\ov/ 
y/Ka*b bo do CoAt, so 

{p cvcvyo^c, it vc-fuscs *to Commit 

^ Codt, a^d mavks up problems 

be- 


public class RemoteReader implements 
boolean[] checkboxState = null; 


,I 

satBox.i ； 


Bob’s BeMBox.java 



String nameToShow 
Obj ect obj = null; 


null; 



lunnable 


public void run () { 

try { 

while((obj=in.readObject()) != null) { 

System.out.println("got an object from server") 
System.out.println(obj.getClass()); 

String nameToShow = (String) obj; 
checkboxState = (boolean[]) in.readObj ect(); 
if (nameToShow. equals (POKE_START_SEQUENCE) ) { 

playPoke () / 

nameToShow = "Hey! Pay attention."; 

} 

otherSeqsMap.put (nameToShow^ checkboxState); 
listVector.add(nameToShow); 
incomingList.setListData(listVector); 

} // close while 

catch(Exception ex) {ex.printStackTrace();} 

// close run 


private void playPoke () { 

Toolkit. getDefaultToolkit () .beep (); 

} 

// close inner class 
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version control 



E%ettciSe 


Conflict Resolution: Here’s the file the version control software kicked back to Bob, with all the 
conflicts marked. What should the final code look like that Bob commits back in? 


public class RemoteReader implements Runnable 
// variable declarations 
public void run () { 

try { 

// code without problems 

<<<<<<< .mine 

if (nameToShow. equals ( 

PICTURE 一 START 一 SEQUENCE)) { 

receive JPEG (); 

} else { 

otherSeqsMap• put ( 

nameToShow, checkboxState); 
listVector.add(nameToShow); 

/ incomingList.setListData(listVector); 

// now reset the sequence to be this 



public class RemoteReader implements 
Runnable { 

// variable declarations 
public void run () { 

try { 

// code without problems 



if (nameToShow. equals ( 

POKE 一 START 一 SEQUENCE) ) { 

playPoke (); 

nameToShow = "Hey! Pay attention. 11 ; 

} 

otherSeqsMap.put ( 

nameToShow,, checkboxState); 
listVector. add (nameToShow); 
incomingList . setListData(listVector); 
»»»> .r2 

} // close while 
// more code without problems 
} // close run 
} // close inner class 


tKe o,es tKat u ? to tKe %»»» . ， 2- tKe 

scwcv- 
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resolving conflicts 



public class Remote 
// variable decla 
public void run() 
try { 

// code without 

<<<<<<< .mine 

if (nameToSho 

receiveJPEG 
} else { 

otherSeqsMa 

na 

listVector. 

incomingLis 


// now rese 


if (nameToSh 

playPoke () 
nameToShow 

} 

o therSeqsMap 
nam 

listVector.a 
incomingList 
>»»» .r2 

} // close whil 

// more code with 
} // close run 
} // close inner cl 


Conflict Resolution: Here’s the file version control kicked back to Bob with both changes in it. 
What should the final section look like that Bob commits back in? 


public class RemoteReader implements Runnable { 

// variable declarations 
public void run () { 

try { 

while ((obj = in.readObj ect()) != null) { 

System.out.printIn("got an obj ect from server"); 
System.out.printIn(obj.getClass ()); 

String nameToShow = (String) obj; 
checkboxState = (boolean[]) in.readObj ect(); 
if (nameToShow.equals (PICTURE 一 START 一 SEQUENCE> > { 

receiveJPEG(); 

} 

else { 

if (nameToShow.equals (POKE—START 一 SEQUENCE> > { 

playPoke(); 

nameToShow = "Hey! Pay attention. 

} 


otherSeqsMap.put(nameToShow, checkboxState) 
listVector.add(nameToShow); 
incomingList.setListData(listVector); 

// now reset the sequence to be this 

} 

} // close while 

} catch (Exception ex) { 
ex.printStackTrace (); 

} 

// close run 
// close inner class 


i\\t 

i\\t 

SO yit 

*bo 


Make su\rc you 

delete the 

(<«««, 

二二二二二二二， 
>»»»). 


Make these changes to your own copy of 
BeatBox . j ava, and commit them to 


your code repository: 


Fi\rst -tell^Subvc\rsioh you \rcsolvcd "the ih -the -file 

usih 9 Vsolved” dommahd ahd the path io the -file. 


/ou skip this 
i-p you d\d^i 

plly 3祍 a co^Wci 
Subvc^sioh. 




I^Ioyj, *b^C -f ile 

•to your sc\rvc\r, 
you did. 




hfsd> svn resolved sre/headfirst/sa/chapter6/BeatBox.java 
Resolved conflicted state of 'BeatBox.java ' 

hfsd> svn commit -m ''Merged picture support with Poke stuff 
Sending src\headfirst\sd\chapter6\BeatBox.java 

Transmitting file data . 

Committed revision 3. 

hfsd> 
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version control 


Now show the customer 



□ o 

□ □ 

□ GO 

□ O 
O □ □ 

□ □□ 

□ □ 

□ p o 

□ □ p 

□ DO 
n □ □ 
O □ □ 

naa 

□ □ □ 
□ □□ 
□ □ □ 


□ □ o 

□ □ □ 
QDU 
Q Q Q 

□ □ O 

□ □ □ 

□ □口 

□ P □ 

c □ n| 

□ DO 

□ □ O 
u u uj 

□ P P 

□ □ □ 
□ □ □ 
□ □ □ 


£4, 




Ah—there's that alert sound- 
and nice pictures too. You guys 
really got your stuff together. 


Skfral PkUii i 


p Ch . d Pokc i!2d Schd 

wovk. 


Dumb Questi9ns 



I see how checking out and committing works, but how do 
other people on the team get my changes? 

Once you’ve got your project checked out, you can run svn 
update. That tells the version control server to give you the latest 
versions of all files in the project. Lots of teams run an update every 
morning, to make sure they’re current with everyone else’s work. 

This whole conflict thing seems pretty hairy. Can’t my 
version control software do anything besides erroring out? 

Some can. Certain version control tools work in a file locking 
mode, which means when you check out files, the system locks 
those files so no one else can check them out. Once you make your 
changes and check the files back in, the system unlocks the files. 
This prevents conflicts, since only one person can edit a file at a time. 
But, it also means you might not be able to make changes to a file 
when you want to; you might need to wait for someone else to finish 
up first. To get around that, some locking version control systems 
allow you to check out a file in read-only mode while it's locked. 

But that’s a bit heavy-handed, so other tools like Subversion allow 
multiple people to work on the same file at once. Good design, good 
division of labor, frequent commits, and good communication help 
reduce the number of manual merges you actually have to do. 


What is all this trunk business you keep saying to ignore? 

The Subversion authors recommend putting your code into 
a directory called trunk. Then, other versions would go into a 
directory called branches. Once you’ve imported your code, the 
trunk thing doesn’t really show up again, except during an initial 
checkout. We'll talk more about branches later in the chapter, but for 
now, stick with the trunk. 

Where are all of my messages going when I do a commit? 

Subversion keeps track of each time you commit changes into 
the repository and associates your message with those changes. 

This lets you look at why people made a certain change—for 
instance, if you need to go back and figure out why something was 
done. That’s why you should always use a sensible, explanatory 
message when you do a commit. The first time you go back through 
old commits and find “I changed stuff as the log message, you’ll be 
pretty cranky. 

Do I have to commit all of my changes at the same time? 

Nope! Just put the path to the filename on the commit 
command like you did for the resolved command. Subversion 
will commit just the file(s) you specify. 
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dealing with older code 


More itcratiows, more stories... 

Things are going well. The customer was happy with our Poke and 
Picture support, and after one more iteration, felt we had enough 
for Version 1.0. A few iterations later and everyone’s looking 
forward to Version 2.0. Just a few more stories to implement... 



Just like every other iteration, we start 
pulling tasks off of the stories and assigning 
them to people. Things are moving along 
nicely until... 
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version control 


Standup meeting 



Bob: Hey guys. Good news: I’m just about done with the Windows 
Messenger version, and it’s working well. But there’s bad news, too. I just 
found a bug in the way images are handled in our Send Picture feature 
from way back in the first iteration. 

Laura: That’s not good. Can we wait on fixing it? 

Bob: I don’t think so — it’s a potential security hole if people figure out 
how to send a malicious picture. The users will be pretty annoyed over 
this. 

Mark: Which means the customer is going to be really annoyed over 
this. Can you fix it? 

Bob: I can fix it — but I’ve got a ton of code changes in there for the 
new story, the log files, that aren’t ready to go out yet. 


Laura: So we’re going to have to roll your changes back and send out a 
patched 1.0 version. 


Mark: What do we roll it back to? We have lots of little changes to 
lots of files. How do we know where version 1.0 was? 

Bob: Forget version 1.0, what about all of my work?? If you roll back, 
you’re going to drop everything I did. 





The team’s in a tough spot — there’s a pretty serious bug in the released 
version, but there’s a lot effort invested in the new version. The new 
version isn’t ready to go out the way it is. What would you do? 
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dealing with multiple releases 


Wc have more thaw one version of our software... 


The real problem here is that we have more than one version of our software — or 
more accurately, more than one version of our source code — that we need to make 
changes to. We have version 1.0 of the code built and out there, but Bob found a 
pretty serious bug. On top of that, we’ve got version 2.0 in the works, but it’s full of 
untested, unworking features. 

We need to separate them somehow... 







PeatPox Pro 1.0 










You started 
Head W Java- 


y/Kcv-c you v/vapped 
up: \/cvsior\ 1-0 ok *tKc 
sof*ty/an. bi》 
pav-ty-lo*ts ok dvmkm^ . Kov/ 
dould *tKcv-c be buy?? 


Vo 


u hck-c. 



TV — 


BULLET POINTS - 

■ Bugs to released versions are usually a higher priority to 
the customer than implementing new features. 

■ Your bug fixes should affect released software and still be 
implemented in in-progress versions of your software. 

■ Effective bug fixing depends on being able to locate 
specific versions of your software and make changes to 
those versions without affecting current development. 


You’ll always kave tension 
between tugs cropping up 
in released versions，anct 
new features in upcoming 
versions. It’s up to you to 
work witk tke customer to 

BALANCE tkose tensions. 
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version control 



0 


You keep saying ''Version 1.0,” but what 
does that mean? Weve committed tons of 
changes since then into the repository.... 


By default, your version control software 
gives you code from the trunk. 

You’re right. When you check out the code from your version control 
system, you’re checking it out from the trunk. That’s the latest code 
by default and (assuming people are committing their changes on a 
regular basis) has all of the latest^S^features. 


tall 


二 



File Edit Window Help 


^rstrt an . A 

—est ♦ W 


hfsd> svn checkout file : ///c : /Users/Developer/Desktop/SVNRepo/ 
BeatBo^triinl^^eatBox 

"A *BeatBox\src 
A BeatBox\src\headfirst 
A BeatBox\src\headfirst\sd 
A BeatBox\src\headfirst\sd\chapter6 
A BeatBox\src\headfirst\sd\chapter6\BeatBox.java 
A BeatBox\src\headfirst\sd\chapter6\MusicServer.java 

Checked out revision 1. 

hf sd> 


But we do have the 1.0 code somewhere, 
even if ifs not labeled, right? We just have 
to find it on our server somehow... 


O 


Version control software stores ALL your code. 

Every time you commit code into your version control system, a 
revision number was attached to the software at that point. So, if 
you can figure out which revision of your software was released as 
Version 1.0, you’re good to go. 


File Edit Window Help 


Here’s 七 vcv\s\oy^ 
y>uwkcv- -fov- sc*t 
\i mtvcascs 

y/i 仏 caA towwit 


hfsd> svn commit -m ''Added POKE support •〃 

Sending src\headfirst\sd\chapter6\BeatBox.java 

Transmitting file data . 

Committed revisi01^18^) 


hfsd> — ’ :. 一 : v 
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viewing logs 


&ood commit messages make finding 
older software easier 


You’ve been putting nice descriptive messages each time you committed 
code into your version control system, right? Here’s where they matter. 
Just as each commit gets a revision number, your version control software 
also keeps your commit messages associated with that revision number, 
and you can view them in the log: 


乙於 d ••• 


… 如 d spcdi-fy whith -file bo gei ihc loj (or. 


File Edit Window Help He 


hfsd> svn 


log 


l^IdWhat? 


sre/headfirst/sd/chapter6/BeatBox.java 



Subversion v-espo^ds 
by jivmj us dll o*f 
loa entries (or 
-rile- 

rteve s tV't 

hc^-c s ihc 

I w f w 

*°3 message io 
3 ° with ii 


r5 I Bob I 2007-09-03 11:45:28 -0400 (Mon, 03 Sep 2007) | 52 lines 

Tests and initial implementation of saving message log for Windows. 


r4 I Bob I 2007-08-27 11:45:28 -0400 (Mon, 27 Aug 2007) | 3 lines 

Quick bugfix for 1.0 release to handle cancelling the send picture dialog 


r3 I Bob I 2007-08-24 11:45:28 -0400 (Fri, 24 Aug 2007) | 23 lines 

Merged picture support with Poke stuff. 


r2 I Mark | 2007-08-21 11:45:28 -0400 (Tues, 21 Aug 2007) | 37 lines 

Added POKE support. 


Subv C \rsioh keeps 
who 

wde the 

扣 d wheh. 


rl I Mark | 2007-08-20 20:08:14 -0400 (Mon, 20 Aug 2007) | 1 line 

Initial Import 



Play "Find the features" with the log messages 

You've got to figure out which features were in the software — in this case, 
for Version 1.0. Then, figure out which revision that matches up with. 


Using the log messages above, which revision do you think matches up 
with Version 1.0 of BeatBox Pro? 



out 仫#_ 0 於 
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Now you caw check out Version 1.0 ln 

s(( spc6-f'it \rcv'»s'ioyv Jc todc. \Nt\t gvabbmg 代 visioh 午 . 

o 


Once you know 
which revision to 
check out, your 
version control 
server can give you 
the code you need: 

TW»s ^ 
coAt m a ^ 
d\vc6V'f> 

\Jtri\or\ I 


File Edit Window Help ThatOne 


hfsd> svn checkoul^-^^^ : ///c : /Users/Developer/Desktop/ 
SVNRepo/BeatBox/trurncBeatBoxVl.0 


BeatBoxVl. 0\src / 

A BeatBoxVl.0\src\headfirst 
A BeatBoxVl.0\src\headfirst\sd 

A BeatBoxVl.0\src\headfirs t\sd\chapter 6 

A BeatBoxVl.0\src\headfirst\sd\chapter6\BeatBox.java 

A BeatBoxVl.0\src\headfirst\sd\chapter6\MusicServer.java 

Checked out revision 4. 

hfsd> 


❺ Now you can fix the 
bug Bob found... 



BeatBox.java 


the vc\rsioh dohtv-ol 
ww gives you hov-^al Java todt 
you dah wov-k oh. 


❺ With the changes in 
place, commit the 
code back to your 


server... 


uv. oV., looks like 

sevvev 

7 ou， 

undated to&t 


File Edit Window Help Trouble 



hfsd> svn commit sre/headfirst/sd/chapter6/BeatBox.java -m 
''Fixed the critical security bug in 1.0 release •〃 

Sending src\headfirst\sd\chapter6\BeatBox.java 

svn : Commit failed (details follow) : 

svn : Out of date : VBeatBox/trunk/src/headfirst/sd/chapter6 / 
BeatBox.j ava ' in transaction '6-1' 

hfsd> 


r^jiarpen your pencil 


What happened? 


Why? 


So now what do we do? 
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tagging revisions 


(Emergency) standup meeting 



V,ave a ， *- ? ^u 如 _ …七崎 


Laura: We could check out the version 1.0 code just fine, but now 
the version control server won’t let us commit our changes back in. 

It says our file is out of date. 

Mark: Oh — ya know, that’s probably a good thing. If we could 
commit it, wouldn’t that become revision 6, meaning the latest 
version of the code wouldn’t have Bob’s changes? 

Bob: Hey that’s right — you’d leapfrog my code with old version 1.0 
code. I don’t want to lose all of my work! 

Laura: You still have your work saved locally, right? Just merge it in 
with the new changes and recommit it. You’ll be fine. 

Bob: Uggh, all that merging stuff sucks; it’s a pain. And what about 
the next time we find a bug we need to patch in Version 1.0? 

Mark: We’ll have to remember what the new 1.0 revision is. Once 
we figure out how to commit this code, we’ll write down the revision 
number and use that as our base for any other 1.0 changes. 

Laura: New 1.0 changes? Wouldn’t we be at Version 1.1 now? 

Bob: Yeah, that’s right. But this is still a mess... 


(^Sharpen your pencil 

Write down three 


Write down three problems with the approach outlined above for 
handling future changes to Version 1.0 (or is it 1.1 ?). 


2 . 


3 . 
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Tag your versions 

The revision system worked great to let us get back to the version of the code we 
were looking for, and we got lucky that the log messages were enough for us to 
figure out what revision we needed. Most version control tools provide a better 
way of tracking which version corresponds to a meaningful event like a release 
or the end of an iteration. They’re called tags. 

Let’s tag the code for BeatBox Pro we just located as Version 1.0: 


© First you need to create a directory in the repository for the tags. You only 
need to do this once for the project (and this is specific to Subversion; most 
version control tools support tags without this kind of directory). 


o-f tv-uhk, spe^i-fy 

tags div-cdWy hcv-c- 


n/ova ^ 
to ^ 

辦糾 w 


FN^Edi^Windo^H^^^^jgae 


hfsd> svn mkdir file : ///c : /Users/Developer/Desktop/SVNRepo/BeatBox/tags 

-m ''Created tags directory" 

^===1^ 

Committed revision 6 . 

hfsd > ^ \ 



iW 士 lo 3 message - a^d …七以 it ⑽ ate a vcv«s^. 

TV^is is a cM^t bo 4c project SO Subvc^iort t'radks it 


❺ Now tag the initial 1.0 release, which is revision 4 from the repository. 

M wision 午 0 ( the tv-uhk... 


Subvcvsioh, 
you ercaie a by 
乙 0 PY m 5 vevisior^ 

you y/ar\*t m*to 七 he 
iay div-cd-tov-y. 
Subvcvsio^ ad*tually 
jus 七 vclatcs 
vcvsior\ *bo 

release- 

So what? 


File Edit Windov 




hfsd> svn copy -r 4 file : ^^7 c : /Users/Developer/Desktop/SVNRepo/BeatBox/ 
trunk file : ///c : /Usersj^S^veloper/Desktop/SVNRepo/BeatBox/tags/version-1.0 


■m ''Tagging the 1.0 release of BeatBox Pro. 


Committed revision 6. 


hfsd> 


/Ud we wah-t -to pu-t that dodc 
a -bg called vcv-sioh-I.O 


So what did that get us? Well, instead of needing to know the revision number 
for version 1.0 and saying svn checkout -r 4 . . ., you can check out Version 
1.0 of the code like this: 


svn checkout file : ///c:/Users/Developer/Desktop/SVNRepo/BeatBox/tags/version-1.0 
And let Subversion remember which revision of the repository that tag relates to. 
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branches and tags 



So now I know where Version 1.0 is, great. 

But we still only have the 1.0 code, and need to 
commit those changes. Do we just commit our 
updated code into the Version 1.0 tag? 


No! The tag is just that; it’s a snapshot of the code at the point you 
made the tag. You don’t want to commit any changes into that tag, or else 


the whole “version-1.0” thing becomes meaningless. Some version control 
tools treat tags so differently that it’s impossible to commit changes into tags 
at all (Subversion doesn’t. It’s possible to commit into a tag, but it’s a very, 
very bad idea). 


BUT 


we can use the same idea and make a copy of revision 4 that we 
will commit changes into; this is called a branch. So a tag is a snapshot of 
your code at a certain time, and a branch is a place where you’re working 
on code that isn’t in the main development tree of the code. 


o Just like with tags, we need to create a directory for branches in our project. Instead 十 „ 二 ! 


Use 






to 於 


A 的 








Now create a version-1 branch from revision 4 in our repository. 



i/Vrth Subvcvsioh you dveate a bvaMli jus 七 like a you to^ {Mt 
vevision you y/an*t m*fco divc^vy. I*t ^ i adtually defy 

rt jus 七 sWs i\\t vcvis'io^ you sufflied. 


we waht -to put it ih-to a called 

^sio^l Gjot Vc^rsioh IA bemuse well use 
七 his +o\r Vcirsioh U, l ， Z, d). 
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Tags, branches, and trunks, oh my! 


Your version control system has got a lot going on now, but most of the 
complexity is managed by the server and isn’t something you have to 
worry about. We’ve tagged the 1.0 code, made fixes in a new branch, and 
still have current development happening in the trunk. Here’s what the 
repository looks like now: 





PeatPox Pro 1.0 


trunk 




\y\ OUV 



version-1 


vc v\s\o^ as 蚊如价 

a ^ /.X ^ixes 

3hd WC ^ Oh that Code ； 




㈣ 以: ： 


You 

j?!y.cs {jo vcvs\oy> 
1.0 Codt V^cv-c. 


called ihc ^uhk. 


is 



PeatPox Pro 1.x 


Tags are 
snapskots oi 
your code. You 
skoulct always 
commit to a 
tranck, and 
never to a tag[* 


^^^BUllET POINTS —— 

■ The trunk is where your active 
development should go; it should 
always represent the latest version 
of your software. 

■ A tag is a name attached to a 
specific revision of the items in your 
repository so that you can easily 
retrieve that revision later. 

■ Sometimes you might need to 

commit the same changes to a 
branch and the trunk if the change 
applies to both. 


■ Branches are copies of your code 
that you can make changes to 
without affecting code in the trunk. 
Branches often start from a tagged 
version of the code. 

■ Tags are static— you don’t commit 
changes into them. Branches are 
for changes that you don’t want 
in the trunk (or to keep code away 
from changes being made in the 
trunk). 
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working with branches 


Fixing Version 1.0...for real this time. 

When we had everything in the trunk, we got an error trying to commit old 
patched code on top of our new code. Now ， though, we’ve got a tag for version 
1.0 and a branch to work in. Let’s fix Version 1.0 in that branch: 


o 


\A/c \l 

tW»s 七一 . 



ircvisio^ 灼 umbels. 
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...and commit our changes back in. This time, though, no conflicts: 


TV^c ^' s m 


File Edit Window Help Sweet 


hfsd> svn commit src/headfirst/sd/chapter6/BeatBox.java -m ''Fixed the 
critical security bug in 1.0 release •〃 


Sending 


src\headfirst\sd\chapter6\BeatBox•java 


Committed revision 10. 


hfsd> 


Wc have TWO code bases wow 

With all these changes, we’ve actually got two different sets of code: the 
1.x branch, where fixes are made to Version 1.0, and the trunk, which has 
all the new development. 


0" 

0 " 


Our trunk directory in the repository has the latest and greatest code 
that’s still in development (and Bob applied the security fix there, too). 


We have a version-1.0 tag in our tags directory so we can pull out 


Version 1.0 whenever we want. 

We have a version-1 branch in our branches directory that has all 
of our critical patches that have to go out as a 1.x version without any 
of the new development work. 



po^t w t： ^ r 1 7 

do dcasc vl.l ^ t esc 

? aUV>es, a ve^l l ^ 

l lay 

\fo\A 
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branches, tags, and subversion 


there ^ are no o 

Dumb Questi9ns 


I’ve heard branches are a bad 
idea and should be avoided. Why are we 
talking about them? 

Branches aren’t always a bad thing; 
they have an important place in software 
development. But, they do come with a price. 
We’ll talk about that over the next few pages. 

What else can tags be used for? 

Tags are great for tracking released 
versions of software, but you can also 
use them for keeping track of versions 
as software goes through testing or 
QA—think alphal, alpha2, 
betal, ReleaseCandidatel, 
ReleaseCandidate2, 

External Testing, etc. It’s also a 
good practice to tag the project at the end of 
each iteration. 

Earlier, you said not to commit 
changes to a tag. What’s that supposed to 
mean? And how can you prevent people 
from doing it? 

The issue with commiting changes to 
a tag is really a Subversion peculiarity; other 
tools explicitly prohibit commiting to a tag. 

Since Subversion uses the copy command to 
create a tag, exactly like it does a branch, you 
technically can commit into a tag just like any 
other place in the repository. However, this 
is almost always a bad idea. The reason you 
tagged something was to be able to get back 
to the code just as it was when you tagged it 
If you commit changes into the tag, it's not the 
same code you originally tagged. 

Subversion does have ways of putting 
permission controls on the tags directory so 
that you can prevent people from committing 
into it. However, once people get used to 
Subversion, it’s usually not a major problem, 
and you can always revert changes to a tag 
in the odd case where it happens. 


We’ve been using file:///c:/... for our 
repository. How is that supposed to work 
with multiple developers? 

Great question—there are a couple 
things you can do here. First, Subversion 
has full support for integration with a web 
server, which lets you specify your repository 
location as http://or https://. That’s when 
things get really interesting. For example, 
with https you get encrypted connections to 
your repository. With either web approach, 
you can share your repository over a much 
larger network without worrying about 
mapping shared drives. It's a little more work 
to configure, but it’s great from the developer 
perspective. If you can’t use http access for 
your repository, Subversion also supports 
tunneling repository access through SSH. 
Check out the Subversion documentation 
(http://svnbook.red-bean.com/) for more 
information on how to set these up. 

When I run the log command, I see 
the same revision number all over the 
place. What’s that about? 

Different tools do versioning (or 
revisioning) differently. What you’re seeing 
is how Subversion does its revision tracking. 
Whenever you commit a file, Subversion 
applies a revision numbor across the 
whole project. Basically, that revision says 
that “The entire project looked like this at 
revision 9 ■” This means that if you want to 
grab the project at a certain point you only 
need to know one revision number. Other 
tools version each file separately (most 
notably the version control tool called CVS 
which was a predecessor to Subversion). 
That means that to get a copy of a project 
at a certain state, you need to know the 
version numbers of each file. This really isn’t 
practical, so tags become even more critical. 


Why did we branch the Version 1.0 
code instead of leaving Version 1.0 in the 
trunk, and branch the new work? 

That would work, but the problem 
with that approach is you end up buried in 
branches as development goes on. The 
trunk ends up being ancient code, and all the 
new work happens several branches deep. 
So you’d have a branch for the next version, 
and another branch for the next... 

With branches for older software, you’ll 
eventually stop working with some of those 
branches. (Do you think Microsoft is still 
making fixes to Word 95?) 

To create tags and branches with 
Subversion, we used the copy command. 
Is that normal? 

Well, it's normal for Subversion. That’s 
because Subversion was designed for 
very “cheap” copies, which just means a 
copy doesn’t create lots of overhead. When 
you create a copy, Subversion actually just 
marks the revision you copied from, and 
then stores changes relative to that. Other 
version control tools do things differently. For 
example, CVS has an explicit tag command, 
and branches result in “real” copies of 
files, meaning they take a lot of time and 
resources. 
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(^Sharpen your penci 

With 


With the security fix to Version 1.0 taken care of, we’re back to our 
original user story. Bob needs to implement two different saving 
mechanisms for the BeatBox application: one for when the user is on a 
Mac, and one for when a user is on a Windows PC. Since these are two 
completely different platforms, what should Bob do here? 


What should Bob do? 


Why? 
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avoiding unnecessary branches 


Whew NOT to branch 



Did you say that Bob should branch his code to support the two different features? Modern 
version control tools do make branching cheap from a technical perspective. The problem 
is there’s a lot of hidden cost from the people perspective. Each branch is a separate code 
base that needs to be maintained, tested, documented, etc. 

For example, remember that critical security fix we made to Version 1.0 of BeatBox? Did that 
fix get applied to the trunk so that it stays fixed in Version 2.0 of the software? Has the trunk 
code changed enough that the fix isn’t a straightforward copy, and we need to so something 
differently to fix it? 

The same would apply with branching to support two different platforms. New features would 
have to be implemented to both branches. And then, when you get to a new version, what do 
you do? Tag both branches? Branch both branches? It gets confusing, fast. Here are some rules 
of thumb for helping you know when not to branch: 

branch whew... 


You have released a version of the software that you need to 
maintain outside of the main development cycle. 

You want to try some radical changes to code that you might need 
to throw away, and you don’t want to impact the rest of the 
team while you work on it. 


Po wot branch whew... 

You can accomplish your goal by splitting code into different files 

or libraries that can be built as appropriate on different platforms. 


You have a bunch of developers that can’t keep their code compiling in 
the trunk so you try to give them their own sandbox to work in. 





The Zen of good branchmg 


Branch only when you absolutely have to. Each branch is a 
potentially large piece of software you have to maintain, test, 
release, and keep up with. If you view branching as a major decision 
that doesn’t happen often, you’re ahead of the game. 
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■ ft 


and Pob finished Vcrsiow 1.0 (so he says) 



Guys, all of my code is checked in but 
nothings working. It should compile, but 
let me know if you have problems building 
something—I might have missed a file. 



We’ve come a long way in this chapter, but there are 


that 

version control alone just can’t fix...Gan you list some troubles 
that Bob can still get into, even if he uses version control to 
manage his code? 


Wc fixed Version 1 





_ 



ItfRf) 





• 

Ufll 
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What version control does 


Lets you create a repository to keep your code in a single place to 
ease backup and recovery. 

Lets multiple people check out copies of the code and work 
efficiently as a team. 

Lets multiple people check changes back into the repository and 

distribute them to the rest of the team. 

Keeps track of who changes what, when, and why. 

Branches and tags code so you can find and change versions of code 
from way back when. 

Rolls back changes that never should have happened in the first place. 
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Version control caw't make sure your 
code actually works... 


version control 



Wouldn’t it be dreamy if there was 
a tool that made sure my code actually 
compiled and worked before it showed 
up in a broken customer demo? But I 
guess it's just a fantasy... 
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Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter, 


you learned about several techniques to keep 


you on track. For a complete list of tools in the 


book, see Appendix ii. 


Dgveloywe 於七 


s 


Use a vcv-s\oy\ coY\bro\ *tool *to 七 
d\siMt m your so^ Wc to 

youv* 七“州 

Use lay ^ kcc ? bracV major 

• ， - bcratio^s, releases, ttCJ 

Use Wa^cs {p mamtam a 

do ? Y o*f your dodc, Ut WaWA 

absolutely ^ 


扣 C SOnr>C 

the key 
tc^hhi^ucs you 

ih -this 
匕 hapiev … 


... ar^d sor^c ^ 

卜 6 咖 bcWmd 

从 osc 


2 




Akys khow wheve chafes should (a^d 
shouldh ， *t) go 

^ how 讪纴 ^odt wehi a giv Ch 
please - ahd be able io h> ii 

Coh^rol dodc 5hd disthbuti, 


；iOh 


BULLET POINTS - 

■ Back up your version control 
repository! It should have all 
of your code and a history of 
changes in it. 

■ Always use a good commit 
message when you commit 
your code—you and your 
team will appreciate it later. 

■ Use tags liberally. If there’s 
any question about needing 
to know what the code 
looked like before a change, 
tag that version of your code. 

■ Commit frequently into 
the repository, but be 
careful about breaking other 
people's code. The longer 
you go between commits, 
the harder merges will be. 

■ There are lots of GUI tools 
for version control systems. 

They help a lot with merges 
and dealing with conflicts. 
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(parpen your pencil 

Solution 


Write down three problems with the approach outlined above for 
handling future changes to version 1.0 (or is it 1.1 ?). 

1. You r\ttd /to keep. what y^y}^}OY)S Ofl wi-th v/hat. vcvfsiop o( the sof-tway ： c ; . 

2 its jo'mj b) be vevy diWiduli "to keep Z O todt -fv-orw sjippmj *m*fco vl.x. 

paidiics. 

3. .-fov：. Vc\rsioK>- 2-0. 乙 ould.med 灼 . you 'to- ddete a-sfiU or. 3 ddss... 

.so .mudk. £hcit i£ .would .bjC.yc.vry. xliifidul£.io.kccp. .a. h pat^k AwiitiQirt 
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6 V2 building your code 





Insert tab a into slot b … 


I tried building this thing without 
instructions, and what a mess... 
Who knew you could build a gondola 
out of the parts you’d use to make 
atreehouse? 






It pays to follow the instructions... 

...especially when you write them yourself. 

It’s not enough to use version control to ensure your code stays safe. You’ve also got 
to worry about compiling your code and packaging it into a deployable unit. On top 
of all that, which class should be the main class of your application? How should that 
class be run? In this chapter, you’ll learn how a build tool allows you to write your own 
instructions for dealing with your source code. 


this is a new half-chapter 
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building buildable soffv^are 


developers aren't mind readers 

Suppose you’ve got a new developer on your team. He can check out 
code from your version control server, and you’re protected from his 
overwriting your code, too. But how does your new team member 
know which dependencies he’s got to worry about? Or which class he 
should run to test things out? 






0 :: 二一 


I had no problems 
checking out the code, but there are 
4 classes with main methods. I have no 
idea how to compile or run any of this. 



svn checkout ... 



There are lots of things you could do with source code: 
compile it all at once, run a particular class (or a set of 
classes); package classes up into a single JAR or DLL file, 
or multiple library files; include a bunch of dependencies... 
and these details change for every project you’ll work on. 


rtovi ^ 

心 develop Uovis 

to do 70UV to&t. 


Good code is 



Software must te usable 


easy to USE, 

as well as 


It doesn’t do you much good to put in a version control server 
if you can’t also be sure your code is used properly once it’s 
checked out. And that’s where build scripts come in. 


easy to GET. 
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building your code 


Puildmg your project iw om step 

When someone wants to run your project, they need to do more than just compile 
source code — they need to build the project. Compiling source code into binary files is 
important, but building a project usually involves finding dependencies ， packaging 
up your project into a usable form, and more. 

And since tasks like these are the same each time they’re run, building a project is a 
perfect candidate for automation: using a tool to handle the repetitive work for you. 

If you’re using an IDE to write your code, a lot of this is handled for you when you 
click “Build.” But there’s a lot of work going on when you press that “Build” button: 



Pieces of yqnx project 

一 ㈤ 。 r s 

J SOVAV6C todt 

avxd 一七七办 •• … M>ably s 0 〜 

) -Piles, |i|< 


‘d 。“七 pops y ou ^ / 
代 ady 铋心 


二知 , HTML 
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introducing ant 


Awt: a build tool for Java projects 

Ant is a build tool for Java that can compile code, create and delete 
directories, and even package up files for you. It all centers around a build 
script. That’s a file you write, in XML for Ant, that tells the tool what to 
do when you need to build your program. 


土 , download Aht 4 or, 

http//ahiapa^hc.o^g/ 


TKc steps -bo W»ld Your j'rojet 
avc s-tov-cd ^ )</V 1 L -f 
usually 竹 bull 


build -file vcfvcsc^ts 


This whole -Pile is 

called 3 bujji sdy-iptl 


needed io build 
youir plr。〆 is bvokch up 
•… "to sicys 匕 ailed ㈣也 

E 此 h -tavget Uyy hTve 

OhC 


rou 


a 


, u Wst k»dk oW a w.ld ^ 

a smMc tommav^d. t 

default 

ay^a Uov/s ”yr \^brUho^ 
l~Fiie Edit Window Help Dolt 


hfsd> ant 

Buildfile: build.xml 


init: 



〈project name= 5， HFSDC 


㈣ ， ’ 祕 _ ，，如，， basedir^ 


name=，， src ，， Jocati 


〈property 
〈卿 ㈣ name= ” 

property name=^ - locatlo ^bi n y> 

Jn strumentedV> m ~ mstru ^ntcd- location=- bin . 

property nam e =，， rep 出 . 

. P ° rtdlr J ocation=^ r eportdirV> 

<target name=- c Jean 55 > 


，> 


</ target> 


Jeiete dir=^{ bin y y> 

SHE’S ?:， 


v> 


y> 


tura.ser ，，/〉 


〈target name= ,, i n i t ^ > 

:士 ir *= 5 l{bin}V> 

^{reportdir} ,, /> 


〈 / targef> 


^kdir dir 
mkdir dir 


’${bi 


切 -instrumentprn，. 


/\ 


this use, /U Scales a div-cd^v-y 士 udu 代 … 

\ wo -rk: s \ HFSD \ "hBovr \ h i n 


[mkdir] Created dir : C:\Users\Developer\workspaces\HFSD\BeatBox\bin 
[mkdir] Created dir : C:\Users\Developer\workspaces\HFSD\BeatBox\dist 

...Compiles todt m*to 七七 s*tvu^*tuvc. 

compile : J 

[javac] Compiling 4 source files to C:\Users\Developer\workspaces\HFSD\BeatBox\bin 


dist: 


[jar] Building jar : C:\Users\Developer\workspaces\HFSD\BeatBox\dist\BeatBox.jar 


BUILD SUCCESSFUL 
Total time : 16 seconds 


...Ad builds a ^j| c 


hfsd> 
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building your code 


Projects, properties, targets, tasks 


An Ant build file is broken into four basic chunks: 


o 


Projects 

Everything in your build file is part of a single project: 

〈project name=’’BeatBox" default= ,, dist ,/ >. 

Your project should have a name and a default target to run when 
the script is run. 




\rcpvcscr\*tcd 
by a 於 )<ML 


tvcv-vtw.^ cUc ^ waa 

is nested ms'«dc 


⑬ Properties 

Ant properties are a lot like constants. They let you refer to values in the 
script, but you can change those values in a single place: 

A property 〈property name=” vers ion” value=’’l. 1 ” /> 



s 


has a 

3hd a value 


〈property name 
〈property name 


"sre" 


location ： 


rr src r/ 


/> 


Gh use piropcirtics with 

七。 Pdye},|ik c this. 


^xerces-src ,A 


You iasc lotatior\ mstcad o-f value 
•，- f youVc dcal>^5 

Targets 

You can group different actions into a target, which is just a set of work. 

For example, you might have a compile target for compilation, and an 

init target for setting up your project’s directory structure. a, 1 « V^s a v^d^C) and 

o ? Wall 7 a ^ ^ 

must be v-uv\ bc-fovc 


location= 〃 ${sre}/xerces 〃 /> 


A tav-get has 

3 buh^h o-f 

"t^sks hes-ted 
withih i-t. 

o 


<target name= 〃 compi1e 〃 depends= 〃 init〃> 



TViS m3kcs 

a r\t^i 

divc^*tov ， Y > 
usm^ 
value o-f 
svt p\ropcv*ty- 


Tasks 

Tasks are the work horses of your build script. A task in Ant usually maps 
to a specific command, like j avac, mkdir, or even j avadoc: 

<mkdir dir=’’${src}’’> 

<javac srcdir="${src}" destdir="${bin}" /> 



o 


m ^ '〔frit 

w 



The syntax here is particular to Ant, but the 
__ t principles work with all build tools, in any language. 

*-V ^ Ant is great for Java, but not everyone uses Java. For now, 

though, focus on what a good build tool gives you: a way to 
manage projects, constants, and specific tasks. In a few pages, we’ll talk about 
build tools that work with other languages, like PHP, Ruby, and G#. 
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more exercises 



Are you kidding? I'm supposed to 
learn a whole new language just so 
I can compile my project? 


No... you’re supposed to learn a new 
tool so someone (or something) 

ELSE can build your project. 

It’s easy to see a build tool as just one more thing to 
learn and keep up with. But most build tools, like Ant, 
are really easy to learn. In fact, you’re just about to put 
together your first build script, and you already know 
more than you think! 

On top of that, your build tool is just that: a tool. It 
helps you get things done faster, especially over a lot of 
projects. You’ll learn a little bit of syntax for your build 
tool, and hardly need to learn anything else about it. 

Oh, and remember: the build tool is for your team, 
not just you. While you may know how to compile your 
project, and keep up with its dependencies, everyone else 
might not. A build tool and build script lets everyone 
on your team use the same process to turn source code 
into a running application. With a good build script 
all it takes is one command to build the software; it’s 
impossible for a developer to accidentally leave a step 
out — even after working on two other projects for six 
months. 
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building your code 



Ant Build Magnets 

Ant files are easier to use — and write — than you think. Below is part 
of a build script, but lots of pieces are missing. It’s up to you to use the 
build magnets at the bottom of the page to complete the build script. 


Pu 七 

elements 
-to domplctc 七 he 
bu'lld ^rwl -f ile- 


〈project name="BeatBox 〃 default="dist"> 

〈target name=’’init’’ . ，， 

description="Creates the needed directories ’〉 


</target> 

〈target name="clean" ■ ■ ■ 

description="Cleans up the build and dist directories. > 


</target> 

〈target name="compile" depends="init 
description:"_ 


rr 


u 


> 


</target> 

〈target name=’’dist’’ depends 




rr 


description= ,/ PcLcka.ges up BeatBox into BeatBox. j ar > 


Seems like theme avc 
a Couple extv-a 

so be ^airc-ful. 


</project> 


^"^STt/BeatBox. jar- 


Compiles the 


Compiles the binary files to the sre directory. 

<jarc 


to the bin di: 
dir="bin"/> 


debug: ’’ true 


/> 




clea] 


dist 


dis. 


compii, 


;rc 


u 


: delet< 


ilete dir: 


basedir= ,, bin i 


<mkdijr dir = ^/> 


</target> 


l> 
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a full build script 



Ant Build Magnet Solutions 

Your task was to reassemble a working build file for building 
the BeatBox application. 


〈project name="BeatBox 〃 default^ 'disj ■"匕 
<target name=’’init‘ 

the needed directories 


TV^c java 乙 
-task 

•、ava todc 
sW，v 

av^d 

classes *m 
i\\t dcstd»v| 


ttcv-cs *tV^ 

-tavyb- 


Cmkdir 


' 


Cmkdir dir= 〃 dist"/>< 


</ta 


认 dVr” 女 


<target name^^clean 


/ou syct\(y -the default 

target -to dal I Cm -this 
"> ^3sc ； dist) i-f -the pevsoh 
\ruhhihg docsh ； t 

spc^i-Py ohc. |h gchcv-al 
"this should do cvcv-y-th'mg 
1 七 ^ceds "to do -fco yt 
you\r -P\rorw zjtYo {o 

\ruhhih 0 . 




rr, 


<delete dir="dist "/ 七 

</target> 


ns up the build and dist directories ’’〉 

TV.c delete task ^ delete 


丁 ” ⑽ 7c；；s W s ? e^Y^ 


<target 

)tion =, l Compiles the source files to the 



ir: 


</target> 


^ , 

\ Compi 


directory. 


n 


> 


estdir="bin"P/> 


depends 



ii tav-yt- 


dompilc, y/hidh m -tuinr^ 



Ea^h -tavgei 

匕 have a 

dcs^v-ip-tioh 

"that is 

pv-ih-ted i-f 
you ask Aht 
xo display 
project 
ih-Povma-tioh. 
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building your code 


My project isn’t in Java—do I still 
need a build tool? 

Probably, and depending on what 
environment you’re working in, you might 
already be using one. If you’re developing 
in Microsoft Visual Studio, you’re almost 
certainly already using their build system, 
called MSBuild (open your csproj file 
in Notepad...seriously). It uses an XML 
description of the build process similar to the 
way Ant does. Visual Studio started that file 
for you, but there's a whole lot more MSBuild 
can do for you that the IDE doesn’t expose. 

If you’re not in Visual Studio but are doing 
■NET development, you might want to check 
out NAnt. It’s basically a port of Ant for the 
■NET world. Ruby uses a tool called rake to 
kick off tests, package up the application, 
clean up after itself, etc. 

But there are some technologies, like Perl 
or PHP, where build scripts aren’t quite as 
valuable, because those languages don’t 
compile or package code. However, you can 
still use a build tool to package, test, and 
deploy your applications, even if you don’t 
need everything a build tool brings to the 
table. 

I’m using an IDE that builds 
everything for me. Isn’t that enough? 

It might be enough for you, but what 
about everyone else on your team? Does 
everyone on your team have to use that 
IDE? This can be a problem on larger 
projects where there's an entirely separate 
group responsible for building and packaging 
your project for other teams like testers or 
QA. 

Then there are tasks that your IDE doesn’t do... 
(If you can’t think of anything like that, we’ll 
talk about some great ones in the next few 
chapters). In general, if your project is more 
than a one-person show (or you want to use 



any of the best practices we’re going to talk 
about in the next few chapters) you need to 
think about a build tool. 

Where did you come up with those 
bin, dist, and src directory names? 

Those directories are an unofficial 
standard for Java projects. A few others 
you’re likely to see are docs for generated 
documenation, generated for things 
like web-service-generated clients and stubs, 
and lib for library dependencies you might 
need. 

There's nothing about these directory names 
that’s set in stone, and you can adjust your 
build file to deal with whatever you use 
on your project. However, if you stick with 
common conventions, it makes it easier 
for new team members to get their heads 
around your project. 

Why are you even talking about 
Ant? Don’t you know about Maven? 

Maven is a Java-oriented “software 
project management and comprehension 
tool." Basically, it goes beyond the smaller- 
scale Ant tasks we’ve been talking about 
and adds support for automatically fetching 
library dependencies, publishing libraries 
you build to well-known places, test 
automation, etc. It’s a great tool, but it masks 
a lot of what’s going on behind the scenes. 

To get the most out of Maven you need to 
structure your project in a particular way. 

For most small- to medium-sized projects, 
Ant can do everything you’ll need. That’s 
not to discourage you from checking out 
Maven, but it’s important to understand the 
underlying concepts that Maven does such 
a great job of hiding. You can find out more 
about Maven at http://maven.apache.org/. 


What should my default target be? 
Should it compile my code, package it, 
generate documentation, all of the above? 

That really depends on your project. If 
someone new was to check out your code, 
what are they most likely looking to do with 
it? Would they want to be able to check 
out your project and expect to be able to 
run it in one step? If so, you probably want 
your default target to do everything. But 
if “everything” means signing things with 
encryption keys and generating an installer 
with InstallShield and so on, you probably 
don’t want that by default. A lot of projects 
actually set up the default target to output 
the project help information so that new 
people can see what their options are and 
pick appropriately. 

The build.xml file has directory 
names repeated all over the place. Is that 
a good idea? 

Great catch! For a build script the size 
of the one we’re using here, it's OK. But if 
you’re writing a more complex build file, it's 
generally a good idea to use properties to 
let you define the directories once, and refer 
to them by aliases throughout the rest of the 
file. In Ant, you’d use the property tag 
for this, like on page 223. 

CouldrVt I just do all of this with a 
batch file or shell script? 

Technically, yes. But a build system 
comes with lots of software-development- 
oriented tasks that you’d either have to write 
yourself or lean on external tools to handle. 
Build tools also integrate into continuous 
integration systems, which we’ll talk about in 
the next chapter. 
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habits of good build scripts 


&ood build scripts... 


A build script captures the details that developers probably don’t need to know right 
from the start about how to compile and package an application, like BeatBox. The 
information isn’t trapped in one person’s head; it’s captured in a version-controlled, 



should do d -few 


generate documentation 


Remember those description tags in the 
build file? Just type ant -pro j ecthelp 
and you’ll get a nice printout of what 
targets are available, a description of each, 
and what the default target is (which is 
usually what you want to use). 


Yo^ build -tool pvobably h< 

•tscll ahd youv cv 

户 … W u— 以 如 d J, 


File Edit Window Help Huh? 


hfsd> ant -projecthelp 
Buildfile : build.xml 

Main targets : 

clean Cleans up the build and dist directories. 
compile Compiles the source files to the bin directory, 
dist Packages up BeatBox into BeatBox.jar 

init Creates the needed directories. 

Default target: dist 

hfsd> 


•••compile your project 

Most importantly, your build scripts compile the code in your project. And in most scripts, you want a 
single command that you can run to handle everything, from setup to compilation to packaging. 


File Edit Window Help Build 


tteve you 乙扣 

see 七 “ -tav-jet 

ouv build/ 
sdrift *tclls ( 

*to 

dis*t iav-yt by > 
default but y 
•m order *to do 
•bKat, \i V^as -to 
V-un C-omf'ilC) 

\Y\ OV"dcV" *to do 
*i*t V^as -to 
\rur\ mrt. 


hfsd> ant 

Buildfile : build.xml 
init: 

[mkdir] Created dir : C:\Users\Developer\workspaces\HFSD\BeatBox\bin 
[mkdir] Created dir : C:\Users\Developer\workspaces\HFSD\BeatBox\dist 

compile : 

[javac] Compiling 4 source files to C:\Users\Developer\workspaces\HFSD\BeatBox\bin 


dist 


[jar] Building jar : C:\Users\Developer\workspaces\HFSD\BeatBox\dist\BeatBox.jar 


BUILD SUCCESSFUL 
Total time : 16 seconds 

hf sd> 
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building your code 



This is cool. But I saw there s a clean 
target in the build file we haven’t talked 

about yet... 


s — 


Good catch — a clean target is there to clean up 
the scraps of things that compiling leaves laying 
around. It’s important to have a target that will 
get the project back to what it would look like if 
you checked the project out from the repository. 
That way, you can test things from a new 
developer’s perspective. 



咖 _ by build— ， p ， o jed t 


•••clean up the mess they make 

The final target we’ll discuss in the BeatBox build script deletes the directories created during the build 
process: the bin directory for compiled classes and the dist directory for the final JAR file. 


S'mtc dis*t is 

dc-fault -tav-jet 
V^avc -to 

tell 

"to 


you V^avc *1 



File Edit Window hvo Scrub 


hfsd> ant clean 
Buildfile : build.xml 


clean : 


[delete] Deleting directory C:\Users\Developer\workspaces\HFSD\BeatBox\bin 
[delete] Deleting directory C:\Users\Developer\workspaces\HFSD\BeatBox\dist 


BUILD SUCCESSFUL 


Total time : 3 seconds 


hfsd> 


M ⑽ s 如 delete tasks to 
U\> i\\t km ar^d d*»st a^d 

remove dll 
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even more build script tricks 


ftood build scripts go PEYONP the basics 

Even though there are some standard things your scripts should do, you’ll find 
plenty of places a good build tool will let your script go beyond the basics: 



Reference libraries your project needs 

You can add libraries to your build path in Ant by using the 
classpath element in the j avac task: 


: 〃 src 〃 destdir= 〃 bin〃> 


<j avac sredir 
<classpath> 

<pathelement 1 ocation=”libs/ j unit • j ar’’/> 
<pathelement location=’’libs/log4j • jar’’/> 
</classpath> 

</javac> 


Ea 匕 h pathdcrwch-t ponvts "to a JAR 
■to add -to the classpath. You cav) also 
pomt -to a di\rcd-to\ry i-f you v\ttd "to. 




If your project depends on libraries you don’t want to include in your 
libs directory, you can also have Ant download libraries using FTP, 
HTTP, SGP, etc., using additional Ant tasks (check out the Ant task 
documentation for details). 



Run your application 

Sometimes it’s not just compiling your application that requires some 
background knowledge; running it can be tricky, too. Suppose your 
app requires the setting of a complex library path or a long string of 


command-line options. You can wrap all of that up in your build script 
using the exec task: 

<exec executable= 〃 cmd〃> 

<arg value=’’/c’’/> 

<arg value= 〃 iexplorer•exe〃/> 

<arg value=’’http : / /www. headf irstlabs . com/’’/> 



system 細咖 k obviously — 令 

*to be Pern 七 

•try *to run *»c%\>lorcr.c%c Lmu%. 


</exec> 
or the j ava task: 



(Ut do 3。 {o Head Fi^rsi Labs) 


<java classname= 〃 headfirst.sd.chapter6.BeatBox〃> 
<arg value= 〃 HFBuildWizard〃/> 


<classpath> 
<pathelement 
</classpath> 

</java> 


location=’’dist/BeatBox • j ar’’/> 



|-f you tiiis m a 

you >woir \ ’七 cvev i^avc *to 

aja'm to U\au\\ BcatBo%. 
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Generate documentation 

You’ve already seen how Ant can display documentation for the build 


file, but it can also generate JavaDoc from your source code: 

<javadoc packagenames= 〃 headfirst•sd •*〃 
sourcepath= 〃 src 〃 
destdir= 〃 docs 〃 

windowtitle=〃BeatBox Documentation ’’/〉 

\ There avc oi\\tr elements you mdude 
•m the JavaPot task -to V^cadcvs 

and -footers -for pay i-f you need *to. 


Noie ihai fyy^i 

you\r liTAIL- -Piles 
fo\r you—but it wjrtc 
"the dodumeh-t^-tioh you’ve 
bcch puttih^ o^f. 


Check out code, run tests, copy builds to archival 
directories, encrypt files, email you when the build 
finishes, execute SQL... 

There are lots more tasks you can use depending on what you need your 
build file to do. Now that you know the basics, all of the other tasks look 
pretty much the same. To get a look at the tasks Ant offers go to: 
http :// ant.apache.org/manual/index.html. 



Automation lets you focus on code, not repetitive tasks. 

With a good build script, you can automate a pretty sophisticated build process. It’s 
not uncommon to see multiple build files on a single project, one for each library 
or component. In cases like that, you might want to think about a master build file 
(sometimes called a bootstrap script) that ties everything together. 


you are here ► 


231 






version control your build script 


Your build script is code, too 

You’ve put a lot of work into your build script. In fact, it，s really code^ just like your 
source files and deployment descriptors. When you look at your build script as code, 
you’ll realize there are lots of clever things you can do with it, like deal with platform 
differences between Windows and Unix, use timestamps to track builds or figure out 
what needs to be recompiled — all completely hidden from the person trying to do the 
build. But, like all other code, it belongs in a repository... 

You should always check your build script into your code repository: 


you add a Uc 

"to "the v*cposi-tov-y ; 
yo“e tcllihj 
Subvcirsioh -that i-fc 
should taYt about 
^ilc. Bu-t you - 
heed -to 

that iil Cj cvch a-f-ti 
bcch added. 


£*mdc y/cVc addi'm^ a -f ile *to ouv- 

OU 七 todc, wc ^ subvc^rsioi. add tomm 釙 d 
tell »*b WiA file we added* 


File Edit Window Help Safe 


hfsd> svn add build.xml 



build2.xml 


hfsd> svn commit -m ''Added Ant build.xml file 


Sending build.xml 

Transmitting file data . 

Committed revision 11. 


: C\r 


W 七 r 


hf sd> 


With your build script in the repository, it’s available to everyone else 
when they do an update. Your version control software will track 
any changes to the script, and the script gets tagged with everything 
else whenever you do a release. This means that you won’t have 
to remember all the magic commands you needed to build the 
nostalgic Version 1.0 in a few years at your IPO party! 


Your tuilct script 

is code … ACT 


LIKE IT! Code 

Wongs in a 
version control 


system，wkere it’s 
versioned ， tagged, 
and saved lor 
later use. 
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building your code 


New developer, take two 

We haven’t written any new classes, talked to the customer, broken tasks up 
into stories, or demoed software for the customer...but things are still looking 
a lot better. With a build tool in place, let’s see what bringing on the new 
developer looks like: 





0 :: 二 # ' 




BULLET POINTS 



■ A build tool is simply 

a tool. It should make 
building your project 
easier, not harder. 

■ Most build tools use a 
build script, where you 
can specify what to build, 
several different instruction 
sets, and locations 

of external files and 
resources. 


svn checkout ... 


■ Be sure you create a way 
to clean up any files your 
script creates. 

■ Your build script is code 
and should be versioned 
and checked into your 
code repository. 

■ Build tools are for your 
team, not just you. Choose 
a build tool that works for 
everyone on your team. 




驗 ㈣ 

\)oyj system 
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Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter, 
you learned about several techniques to keep 
you on track. For a complete list of tools in the 
book, see Appendix ii. 




Use a build W ^ WiW— 

test ， ad At^\o^ your 

system 

Most \VU a^c already a \>M 
W u ▲ 蚁 atW 十七 ^am»l»ar ^ tjjat 
{po\ f ar^d you build v/Via*t IPt 

already d°^ s 

Treat Y 歧 Wild T»kc code a^d 

c^tcV \i •• 丄會 “ CoM 


Sor^c 
the key 
tc^hhi^ucs you 
ih -this 


..a^d sowc 




yr\U\^ bcWmd 


nr\i 


2 


^!£E!!^iiVihdip| es 


Buildihg B p\rojc<l*t should be v*cpca*t^blc 
ahd ^ijormS^cd 

Bu ； ld 5M ?^ ^ ^ sia^c 4v oth^ 

3u*tom3*tioh *fcools 

Build s^yis go beyohd just step- 
by-s-tep au-tomatioh 3hd d^h _ 七 | 
^ompilatioh avyd dcploymcht \oyc 
decisions 


； u\rc 


BULLET POINTS - 

■ All but the smallest projects 
have a nontrivial build 
process. 

■ You want to capture and 
automate the knowledge 
of how to build your 
system— ideally in a single 
command. 

■ Ant is a build tool for Java 
projects and captures build 
information in an XML file 
named build.xml. 

■ The more you take 
advantage of common 
conventions, the more 
familiar your project will look 
to someone else, and the 
easier the project will be to 
integrate with external tools. 

■ Your build script is just as 
much a part of your project 
as any other piece of 
code. It should be checked 
into version control with 
everything else. 
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7 testing and c^nt!mi9us integr^fen 


參 



Things fall apart 


I swear, Mac, ril get it working 
again...just give me 48 hours, ril make 
good on my marker, okay? 


O 




0 




Sometimes even the best developer breaks the build. 

Everyone’s done it at least once. You’re sure your code compiles; you’ve tested it over 
and over again on your machine and committed it into the repository. But somewhere 
between your machine and that black box they call a server, someone must have 
changed your code. The unlucky soul who does the next checkout is about to have a bad 
morning sorting out what used to be working code. In this chapter we’ll talk about how 
to put together a safety net to keep the build in working order and you productive. 


this is a new chapter 
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it never rains but it pours 



Things will ALWAYS go wrowg... 

Everyone who’s ever done development knows what it’s like. It’s late, 
you’re on you’re eleventh can of Rock Star energy drink, and you still 
leave out that one ++ operator somewhere. Suddenly, your elegant code 
goes to pieces...bad news is, you don’t realize you’ve got a problem. 

At least, not until you’re demoing the software for your boss. Remember 
the issues we had with Bob’s code in Chapter 6? 


gob's todt seemed -to 
Yiovk m some - 


Tm not hearing any alert. 

And whafs SECRET—POKE— 
SEQUENCE? I*m not impressed. 


O 



XV\c veal pvoklcw v/as ^ 
^elTsu^sea as -tV,e 
^as ^ 七 Wmy 卿七 … 叫 . 



What other kinds of things can go wrong on a development project? 
What about with a small team? Do you have the same problems 
with a bigger team? Different problems? 



oihen. 



□ o □ 
Doa 

□ □o 

□ □□ 
□□□ 
aaa 

□ Do 
ODD 

□□ □ 

□ □□ 

□□□ 

□□□ 

.□on 

y □□ 

□□□ 

口 o □ 


u p □ □ 

□ aoa 
□□□□ 
□□□□ 
□□□□ 

□ □□□ 
□□□□ 
DODD 

□□□□ 

DpaG 

□□□□ 

□□□□ 

□□oa 

□□□□ 

□ □□□ 

□□□□ 


□□□ o 

□ poo 

□ Day 

□ □□□ 
□□□o 

□ □□a 

DGGO 
□Doo 

□□□a 

□ □□□ 

□ □□□ 

□ooo 

□ aaa 

□ p □ Q 

□ □□□ 

□□□ O 


236 Chapter 7 

























































testing and continuous integration 


Standup meeting 



If Bob had just made sure his 
code compiled, none of this 
would even be an issue. 


Bob: I did get it compiling! It took me forever to integrate the changes and 
get everything building again. It’s not my fault. 

Mark: Yeah, the code compiled; it just didn’t work. So he didn’t screw up 
as badly as it looks, really. 

Laura: Didn’t you test things? 

Bob: Well, the code worked fine on my machine. I ran it and everything 
seemed fine... 


Mark: OK, but running your code and doing a quick checkover is not 
really putting your code to the test. 


Laura: Exactly. The functionality of your software is part of your 
responsibility, not just that the code “seems to work ’’； that’s never going to 
wash with the customer... 


Bob: Well, now that we have a version control server and build tool in place, 
this shouldn’t be a problem anymore. So enough beating up on me, alright? 

Mark: Hardly! Our build tool makes sure the code compiles, and we can 
back out changes with version control, but that doesn’t help making sure 
things work right. Your code compiled; that was never the problem. It’s the 
functionality of the system that got screwed up, and our build tool does 
nothing for that. 

Laura: Yeah, you didn’t even realize anything had gone wrong... 


you are here ► 
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black box testing 


There are three ways to look at your system 


Good testing is essential on any software project. If your software doesn’t work, 
it won’t get used — and there’s a good chance you won’t get paid. So before 
getting into the nitty-gritty of software testing, it’s important to step back 
and remember that different people look at your system from totally different 
perspectives, or views. 


wove ov> 七 hese 

dU 切 ? cs of 破，， 

see ** 



Your users see the system from the outside ) 

Your users don’t see your code, they don’t look at the database 
tables, they don’t evaluate your algorithms...and generally 
don’t want to. Your system is a black box to them; it either 
does what they asked it to do, or it doesn’t. Your users are all 
about functionality. 





Testers peek under the covers a little 

Testers are a different breed. They’re looking for 
functionality, but they’re usually poking underneath to 
make sure things are really happening the way you said 
they would. Your system is more of a grey box to them. 
Testers are probably looking at the data in your database to 
make sure things are being cleaned up correctly; they might 
be checking that ports are closed, network connections 
dropped, and that memory usage is staying steady. 





Pevelopers let it all hang out 

Developers are in the weeds. They see good (and sometimes 
bad) class design, patterns, duplicated code, inconsistencies 
in how things are represented. The system is wide open to 
them. If users see a system as a closed black box, developers 
see it as an open white box. But sometimes because 
developers see so much detail, it’s possible for them to miss 
broken functionality or make an assumption that a tester or 
end user might not. 



,.and you need to consider each of these views 

Each view of your system is valid, and you have to test from 
each of those three perspectives. 
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testing and continuous integration 


Plack-box testing focuses 
oh INPUT awd OUTPUT 

Your users are outside your system. They only see 
what they put into the system and what comes 
back out. When you do black-box testing you 
should look for: 






Black-tox testing 


Functionality . Hands down, this is the most important black box testing. 
Does the system do what the user story says it is supposed to do? With black 
box testing, you don’t care if your data is being stored in a text file or a 
massively parallel clustered database. You just care that the data gets in there 
like the story says and you get back the results the story says you should. 




User input validation. Feed your system 3.995 for a dollar amount or 
-1 for your birthday. If you’re writing a web application, put some HTML 
in your name field or try some SQL. The system better reject those values, 


This ish't 
OlrdcirPvo^ssov- 
^Idss hdhdlc 

it’s 

3bou*t i-f d ^us*tomcv- 
Uh buy a dvihk wi-th 
"theiv gi-f-t card. 


and do it in a way that a typical end user can understand. 


Output results. Hand-check numerical values that your system returns. 
Make sure all of the functional paths have been tested (“if the user enters 
an invalid ending location, and then clicks “Get Directions’’".” ） It’s often 
helpful to put together a table showing the various inputs you could give 
the system, and what you’d expect the results to be for each input. 



^.y-y-OV 

avc usually 
last 州 0 

dc7clo^ s tWmk 

about, 七 十 c 

《 Vr ! 七 wost 


State transitions. Some systems need to move from one state to another 
according to very specific rules. This is similar to output results, but it’s 
about making sure your system handles moving from state to state like it’s 
supposed to. This is particularly critical if you’re implementing some kind 
of protocol like SMTP, a satellite communications link, or GPS receiver. 
Again, having a map of the states and what it takes to move the system 
from one to the other is very useful here. 


Boundary cases and off-by-one errors. You should test your system 
with a value that’s just a little too small or just outside the maximum 
allowable value. For example, checking month 12 (if your months go from 
0—11) or month 13 will let you know if you’ve got things just right, or if 
someone slipped up and forgot about zero-based arrays. ' 

usu3 "y ^ 




( Q}r 
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grey box testing 


ftrcy-box testing gets you 
CLOSER to the code 

Black-box testing works great for a lot of applications, but 
there are situations where you need more. Sometimes you 
just can’t get the results out of a system easily without looking 
inside, at least a little. This is particularly true with a lot of 
web applications, where the web interface just moves data 
around in a database. You’ve got to deal with the database 
code as well as the web interface itself. 



Grey-Lox testing 



给 rey - box testing is like black - box testiwg...but you caw peek 


When doing grey box testing, you’re generally looking for the same things as black 
box testing, but you can dig around a little to make sure the system works as it’s 
supposed to below the surface. Use grey box testing for things like: 


Verifying auditing and logging. When important data (or money) is 
on the line, there’s usually a lot of auditing and logging going on inside a 
system. This information isn’t usually available through the normal user 
interface, either. You might need to use a log viewing tool or auditing 
report, or maybe just query some database tables directly. 


But be dav-c-Pul 
^°99 ,h 9 ^Oh-fidchtial 

ih-fov-irna-tioh -to 



UhSMu\red places, 
w 。 〆 七 make 
vight Sov-b o( 
•(Viehds that way... 


Data destined for other systems. If you’re building a system that 
sends information to another system at a later time (say an order for 50 
copies of Head First Software Development) : you should check the output 
format and data you’re sending to the other systems...and that means 
looking underneath what’s exposed by the system. 


System-added information. It’s common for applications to 
create checksums or hashes of data to make sure things are stored 
correctly (or securely). You should hand-check these. Make sure system¬ 
generated timestamps are being created in the right time zone and 
stored with the right data. 

Scraps left laying around. It’s so easy as a developer to miss doing 
cleanup after a system is done with data. This can be a security risk as well 
as a resource leak. Make sure data is really deleted if it’s supposed to be, 
and make sure it isn’t deleted if it’s not. Check that the system isn’t leaking 
memory while it’s running. Look for things that might leave scraps of 
files or registry entries after they should have been cleaned up. Verify that 
uninstalling your application leaves the system clean. 
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testing and continuous integration 





Below is a user story from BeatBox Pro. Your job is to write up three ideas for black or 
grey box tests, and descriptions of what you’d do to implement those tests. 


Title: 


Send a picture 
to other users 


Descriptipn ： … Click ow thc Scwd a Picture^ 

button to send a picture (only JPE6 ： needs to be 
supported) to the other users. They shoujd have 
the option to not accept the file. There arc wo 
size iiwits oh the f iic right now. 


Priority: 


0 


Estimate: 


GST TOr... d small JPE^ *to another usev- 


rteves ov\t *to 


How would you iesi this? 
Dcsd\ribc the test dase ih 
pla.m Eh^lish. 


-> 


t. Test for., 



TWk aboiA*t tVic 
y/ays *fu£.*tioir\ar»*tY m 
usev* s*bov*Y C-oiaIcA be "tcs*tcd) like 
4 ⑼ rt V^dles tWmjs 





$. Test for... 


you are here ► 
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white box testing 



Below is a user story from BeatBox Pro. Your job was to write up three ideas for black or grey 
box tests, and descriptions of what you’d do to implement those tests. 


Title: 


a picture 
toother users 


Description: .Qljcjk OW th?. S.C.Ild a Picture. 

button t.Q a picture lowly/JP.^. needs to he... 

supported), to. the.other. users. .They should .have.. 
theppti.Qii.tP. riot.accept, the .file.,There.^re.wo ■… 
size limits ow. the file riaht.^PW.. 


Priority: 


H 


Estimate: 


up w ， th. Its okay you have 

I oh«... you'll jus-t have mov-c 

ideas \oy actual tes-ts. 


丁， ， 

U ； s is 3 ‘k 一 box iest Also 
仏 at w ^eded sor, c 
^souUcs io support 
—t«t Th^s OK usi,a 
sample i h put is -fi hC . You should 
wsioh-^ohtirol those vcsou^« ; 
though, -f-ov la-tcv- v-cusc. 


These -tests arc a l'«Ulc 
on i\\t s'dc. You 
y\ccd bo ky\ov/ Ko>w Bca*tBox. 
Pvo should V^3\r\dlc *t^csc 
ay\d ^Kcvc 

c%C.cf*tioy\s v/ould kc scirvH 

a 灼 CcYCK o£.c.u\rvcd- 


1. Test for... sehdmj a Small JPE^ -fco a^o*thc\r USCV-. 

—七 "two ms*ta^dcs o-f Bca*tBo 乂 Pvo 0r\ *tKc -fi\rs*t ms*ta 灼匕 e, 

dlidk *thc Sc^d. Pi^uy-c bu*tto^； iVhcri the imajc sclcdtioir) dialog j>ops 

up ? sclcd*t S.^cjlJ IjP3 ,!i.4k QK ： 

Then dhcdk Bv\d make su\rc *tha 七 *thc sctoY\d Bca*tBoy. displays a 
Receive |md^e dialog box. Clitk 0^( h> *t^c Cheek 七 
. thedisplays dory-c^iJy.. 

Z. Test for... se^dma mvalid JPE^ *bo a^othev- usev-. 

与 c 七七 v/o ms-ta^dcs o( BeatBox. P\ro 0 y\ 七 he -fivs*t ms-ta^dc ； 

di.^. *tiic Sc^d Pidtu\rc bu*tto^- iVhc^ "the ima^C sclcd*tioir) dialog poJ> 

up； select l^yalidlmajc j^ a^d dlidk 冰: 

Che 匕 k 七 BeatBox. shows a dialog -tcllmg you 七 *thc imd^e is 

i^yalid a^d be s^t Co^^irm that sedo^d BcatBo^ did. 

.»}ot display .a .Redciyc. (maje. dialog. /i]so ^akc sure 

y/c\rc *th\rovm -f\row\ ci*t^C\r *ms*ta^dc- 


s 


3, TCS"t for … losmj do^^cd*tivi*ty while *tv"a^s-fc\rv-*mg By\ imd^e- 

S*bsi\rt *two .^s-tair\dcs o-f BcatBo^ P\ro. 0y\ -the -f iy-st msta^dc, didk 

Sc^dl Pi^uy-c bu-tto^-. iVho) tiic i^ajc sclc^ii?.^ .p?p^ 人 select 


. 合•.和•七 l*?^3?jP3 .扑 Q ^>： . 

.CKcck .ihai .ihc. seeped s.bp.vys .a. Re.Ccive. J.^.agc. .dial.pg. hp^.And 

t\\tk «. .tVhilc. 社 )?. imajc. is .'ty-cj^s-fey-^m^ (makc.ihc .irnej^C scycy*3l. AlB. 




so i*t v/i)l take a while), kill *thc.sjc 4 o^d BcatBo^ Chc^k 

the -fi|rs-t BcatBo^ displays a. dialog say'mj. -the/tra^s-fcy*. .-failed . 和 d 
that y\o c^dcptio^s y/cy-c 


242 Chapter 7 














































testing and continuous integration 


White - box testing uses inside knowledge 


At the deepest levels of testing, you’ll find white box tests. This is 
where you know exactly what’s going on inside the code, and you 
do your best to make that code break. If you put aside the fact that 
you have to fix the code when it does break, white-box testing can 
actually be fun: it becomes a challenge to dig into code and generate 
problem situations that will cause errors and crashes. 



When doing white-box testing you should be familiar with the code 
you’re about to test. You still care about functionality, but you should 
also be thinking about the fact that method X is going to divide 
by one of the numbers you’re sending in... is that number being 
checked properly? With white-box testing you’re generally looking 
for: 


different branches of code. With white-box testing 
you should be looking at all of your code. You can see all of the if/ 
elses and all the case and switch statements. What data do you need to 
send in to get the class you’re looking at to run each of those branches? 



Most toAt 

^vca*b ⑼ tWmy are 
(xomoy as 

so-6allcd 代 7 
ytW’ - W 七 
about 

o^-f-*bva6k? 


Proper error handling. If you do feed invalid data into a method, are 
you getting the right error back? Is your code cleaning up after itself nicely 
by releasing resources like file handles, mutexes, or allocated memory? 


Working as documented. If the method claims it’s thread-safe, test the 
method from multiple threads If the documentation says you can pass 
null in as an argument to a method and you’ll then get back a certain set 
of values, is that what’s really going on? If a method claims you need a 
certain security role to call it, try the method with and without that role. 

Proper handling of resource constraints. If a method tries to 
grab resources — like memory, disk space, or a network connection — what 
does the code do if it can’t get the resource it needs? Are these problems 
handled gracefully? Gan you write a test to force the code into one of 
those problematic conditions? 



Black 一 box -tcs-tihg 

looked at cvvov 
messages, but whai 
what code 

’e +七 a\rouhd wheh 
"thihjs jo wvohg? 

Thai's whitc- 

-testing ^ 


White-box tests tend to be code-ow-code 

Since white-box tests tend to get up close and personal with the code they’re trying to test, 
it’s common to see them written in code and run on a machine rather than exercised by a 
human. Let’s write some code-on-code tests now... 


you are here ► 
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testing functionality 



E 從 ftdSe 


Below is the block of code that Bob built for the BeatBox Pro demo (the one that failed 
spectacularly), and the two user stories that version of the software was focused on. On the 
next page are three tests that need to pass. How would you test these in code? 


Title: 


S ⑼ d a poke to 

other users … 


TV)CSC sWlCS 

*to v/ovk m 

{\\c dcwo—Y ou 

V^avc *to 七 cs 七 饮 


Description: i 

M.towlQ aend awaiidibkand visual. aJert to tbe| 
.o.tb.cr .in the. ohal tb.6 alerrt.sb.Quld.be.. 

shprt aiid jipttp.Q 抑抑 yiwg ： r：yQ 伽 ⑽; t tryiiig. 
to gefthei.r atteiitip.ii,. 


Priority: 


Estimate: 


toother users . 

moxmto. the 0 th e =J^^ ed _e.. 

蝴 Imitm r ^rnr, m ... 

Pri0rity： S Hs « mate： J 7 J 



Rcw'CW'IdCV' 七 ha 七 

Bob ovcvv/v-o*tc 
i\\t todt b> 

V^dlc 七 V^c 

POWW 一 


Cori\r/\^Tid' 



^ould you 
七 "this Code 
wke suv-c i-fe 

新 ks, cvch i-f 

3ho-fch e<r problem 
^or^cs uP? 
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testing and continuous integration 



Prf mrW'/ fscudotodc .you :十 a 

wou^c, assume you I » s 

just kas\t todc^lcvcl steps you d ^ccd. 

It TGS"f for... a picture s*b|\rt sc^uchde -fco test pid-tuy-?. ^*.^7 


establish a Y\C^I ir\c*tv/o\rk doirmedticm wV^*b ^ 0[A 

se^d ovc\r By\ empty a\r\ray W t\)tt\c bo>ccs Cy\o audio) 

send. .figure .d.^. 丁 L . . j p 

I his o^c is do^t \oy you 

.verjiy. .pidtuv-c. .data .Reived. a»d .displayed .prx>pcv：ly. give you idea o\ 

. "the pseudocode "to use b> 

dcs^v-ibc d -test. 

Z. Test for... a poke start -b> -test J ； o\r poke 

es*tablish a y\c^ network doirmed*boir\ 


3 . TCS"f for... a hojri^al 太 d ^cssajc *thcl*t^s scr\*t *to all diChts. 


iVhat would this "tes-t do? 
This should be pseudocode- 
^odc 3 v*c you 30*1 *to 
have h> wv-itc "to irwplcmch-t 
this -test? 


es*tablish a I^cv/ network doirmc&tio 的 
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you create tests 



BteftctSe 


Below is the block of code that Bob built for the demo (the one that failed spectacularly), and the 
two user stories this version of the software was focused on. Your job was to figure out how to 
white-box-test for at least three problem situations. 


o-f ouv y\C^i s-tov-ics, but dijs 'm*to 
the todt involved- 


tGSt for B This is -to -tes-t the basid pidiuv-c 

-Pu^d-tio^ali-ty, s'mdc i*t was OY\t 

cs-tablish a Y\t^i ^c*two\rk 匕 oirme 匕 "tiem 

. 贈•祕爾仨娜 . 

schd ovcv- by\ empty avv-ay o-f 匕 he 匕 kbo 乂 es (^o audio) 
stv\d -the pd*tuy-c dd'bi 

ycriiy. 七 wrc. daia. yrc^Wcd .孙 d .displayed, prp.per.ly. 

. This ^-depth tha, just 

dg ihe 与 Mf: youVc vcally 

S PM 心 ^ihods, with 

"tCSi* for a poke s*ta\r*t sc«\uc^c *fco *tcs*t -fov- poke -fu^^*tio^ali*ty- 



es*tdblish a r\ev/ ^c*two\rk 6 oirmc^bcm V^ull probably heed ix> 

s^dihe 阶從二计 Mf 二注和•卽战 . 七 his ^ olrks b y 詷枉 u 3 

sc^d ovcv- 3r\ cmp*ty avv-ay dhc^k \>o%ts Cy\o audio) okay 七一七 

!?.. "to 七《七 p^-opcvly ^ u hCC 


vevi-fy 



VVi*bVv a *fccs*t- *feo- POKE-^START . 

SEQUENCE, you s« \( *»t ^a.U bfe 

sV^owmj 'll tv^c tusUm ⑺扣 d avoid a^Y suvp^nscs. 

test for a ^ov-mal *tcx.*t message is sc 灼七 *to all dici^ts. 


: is a 、° u,ke 
七 V\e ^>ttvAV*c test- 


establish B i^c*tv/o\rk doirme 匕 *tio 的 



stv\d *thc message, u Tcs*t messaje^ 
scy\A by\ av-v-ay o( valid Ae 匕 kbo 乂 options p 。/ 七 ^fovyb "to *bcs 七 s*bu*W 

vcy-ijfy -the icsj ： message v/as y-edciyed by all a^d -the 七 V^a 七 should st»ll ^ v/ovk'm^! 

.C.hc^kbp^cs.arc.updated.ihc..ary ： ay.vaJiA.es.. 丁 1S j uS 七巧 »^ov*bnt ^ 


There are lots more tests you could have come up with—things like testing that clicking on one of the messages 
retrieves the checkboxes correctly, and testing for failure conditions. What happens if too many checkbox values 
are sent in an array? Or too few? See how many ways you can break BeatBox Pro. 
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testing and continuous integration 



But aren*t there testing frameworks 
out there to do this for us? Why are 
we writing all this code ourselves? 


Coming up with tests is YOUR job. 

There are lots of good frameworks out there, but they run your tests; they 
don’t write them for you . 决 A testing frameworks is really just a collection 
of tools that help you express your tests. Even though that makes them 
really useful, there are a few things you still need to keep in mind: 

First, you still need to figure out what you have to test. Figuring 
out what to test and how you express that test are usually two different 
things. Regardless of your framework, you need to think about functional 
testing, performance testing, boundary or edge cases, race conditions, 
security risks, valid data, invalid data, etc. 

Next, your choice of testing frameworks is almost certainly 
going to impact how you test. That’s not always a bad thing, but don’t 
forget about it. This might mean you need more than one way to test your 
software. For example, if you decide to use a code-level testing framework 
for your desktop application, you’re still leaving yourself open for bugs in 
your GUI, so you’ll probably want something to test that, too. Another 
great example: say you’re writing a 3-D game. Testing the backend code 
isn’t too hard, but making sure that the game renders correctly and people 
can’t walk through walls or fall through small cracks in your world...well, 
that’s a mess, and no framework can generate those tests for you. 


* AtWIv ， We—ks tan ::一 ： 


Hanging your tests ow a framework 

We’re talking about frameworks, but what does that really mean? The obvious way to 
test is to have someone use your application. But, if we can automate our tests we 
can get paid while tliL lumpuLu Ll^L our otuff be more effective and know that our 
tests are run exactly the same way each time. That’s important, because consistency in 
how a test is run isn’t something humans are very good at. 
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one-click testing 


Testing EVERYTHING with owe step _ 山的 

There are lots more advantages to automating your tests. As well as not 
requiring you to sit there and manually run the tests yourself, you also build 
up a library of tests that are all run at the same time to test your software 
completely every time you run the test suite: 

o Build up a suite of tests 

As your software grows so will the tests that need to be applied to it. At first, 
this might seem a little scary, especially if you’re running tests by hand. Large 
software systems can have literally thousands of tests that take days of developer 
time to run. If you automate your tests you can collect all the tests for your 
software into one library and then run those tests at will, without having to rely 
on having somebody, probably a poor test engineer who looked at you wrong, 
running those tests manually for a day or so. 



Run all your tests with one command 

Once you have a suite of tests that can be run automatically in a framework, the 
next step is to build that set of tests such that they can all be run with just one 
command. The easier a test suite is to run, the more often it will actually be used 
and that can only mean that your software quality will improve. Any new tests 
are simply added to the test suite, and bang, everyone gets the benefit of the test 
you have written. 



Get regression testing for free 

The big advantage of creating a one-command suite of tests that you continually 
add to as you add more code to your software is that you get regression 
testing for free. Detecting when a new change that you’ve made to your 
software has actually introduced bugs in the older code, called software 
regression, is a danger for any developer working with old or inherited code. 

The best way to deal with the threat of regression problems is to not only run 
your own tests for your newly added code, but to run all the older tests as well. 

Now, because you’ll be adding your new tests into your test suite, you’ll get this 
for free. All you have to do is add your new tests to the existing test suite and kick 
things off with one command~you’ll have regression tested your changes. 

^ this \rdics ov\ the 

cxistih^ todc base haviha a 
Suite o\ -tests available to\- 
you "to extend. out 
Chaptcv- lO -Po\r what "fco do 
whch that ish "the ddsc. 
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testing and continuous integration 


O 


Hmm, won’t testing everything every time make 
testing take a long time? Isn’t there a way of tuning 
things so that developers can regression-test everything 
when they need to, and just fit testing in manually 


o 



Tailor your test suites to suit the occasion 

It’s unfortunately true that large unit test suites become ungainly and, 
therefore, tend to get used less. One technique is to break out fast and 
slow tests so that a developer can run all the fast tests often while they are 
changing and adding code, but only run the full suite when they think they 
need to. 

What tests fall into the fast or slow categories is really up to your particular 
project, and which category specific tests fall into can change depending on 
the development work that you are doing. For example, if you have barely- 
ever-changes code that takes a long time to test, then that would be a good 
candidate for the slow test suite. However if you were working on code that 
might well impact the barely-ever-changes code, then you might consider 
moving its tests into the fast test suite while you are working those changes. 

Let’s try it out with a popular free testing framework for Java, called JUnit. 



suite? 


tWeiqre no o 

Dumb Questions 


So how often should we run our entire test 


To dowhload the JUhit 
9° "t° http://v/y/y/juhi-t.ov-0 


You darv also 
up s1o>m yAS\v\^ 

wotks ； see ^ 

-fov wove ov\ 七 hose. 


This is really up to you and your team. If you’re 
happy with running your full test suite once a day, and 
know that any regression bugs will only be caught 
once a day, then that’s fine. However, we’d still 
recommend you have a set of tests that can be run 
much more frequently. 


Keep tke time it takes to 
run your tests as skort as 
possible* Tke longer a test 
suite takes to run, tke less 
often it is likely to t>e run! 
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making the most of a framework 


Automate your tests with a testing framework 


Let’s take a simple test case and automate it using JUnit. JUnit provides common 
resources and behaviors you need for your tests, and then invokes each of your tests, 
one at a time. JUnit gives you a nice GUI to see your tests run, as well, but that’s real! 
a small thing compared to the power of automating your tests. 





七 He OU^t Masses. 


JUhit also has a 
based test v-uhhcv- 
ahd plug-ihs -fov- most 
Popular IDBs. 


Wcirc's a siaii^ 
-filial o-f empty 
匕 he 匕 kboxes that 

be used ih several 
di-PfcirCh-t tests. 


伽 Ua\U 々认 : 0 
• m ^ "' 办 。d 

*tca\rDo>w^O is -fo\r 

up- JUni 七 dal Is 
■this method 
•tes-t is -finished- 


ttcvc^s ar> ad*tual 

You airmotate I 七 

v/rth so 

kr>ov/s I Vs a *tcs*t 

a^d caY\ via 灼 rt. Ti^c 

method jus 七 stY\ds a 

*tcs*t message ar>d a 

dhcdkbo%Sia*tc. 


package headfirst.sd.chapter7; 
import java.io .*； 
import j ava.net.Socket; 
import org.junit.*; 

public class TestRemoteReader 
private Socket mTestSocket; 
private Obj ectOutputStream 


TV 


^ ih scvc ^ 


mOutStream; 


private ObjectlnputStream mlnStream; 

public static final boolean[] EMPTY—CHECKBOXES = new boolean[256] 
@Before 

public void setup() throws IOException { 

mTestSocket = new Socket(”127•0• 0 • 1 〃 4242). 

mOutStream = 

mInStream e = t0UtPUtStream ( mTeStSocket .getOutputStream()) 

new ObjectlnputStream(mTestSocket.getlnputStream ())； 


@After 
public 


void tearDown() throws IOException { 
mTestSocket.close(); 
mOutStream = null ； 
mlnStream 二 null ； 
mTestSocket = null; 




5二聲 

a^d a 如你 “ cs 七 . 


@Test 

public void testNormalMessage()throws IOException { 
boolean[] checkboxState = new boolean[256]; 
chsckboxS 13 .t g [ 0 ] = true/ 
ch g ckboxS1 3 .ts [5] = tirus / 
ch g ckboxS13.t g [19] = true/ 

mOutStream.writeObject (''This is a test message! 
mOutStream.writeObject(checkboxState); 


)； 
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was sci up ih -the sctupO method 
that JUhi-t will alvcady have called. 






testing and continuous integration 


Use your framework to ruw your tests 

Invoke the JUnit test runner, org . j unit. runner . JUnitCore. The 
only information you need to give the runner is which test class to run: 
headfirst. sd. chapter7 . TestRemoteReader. The framework 
handles running each test in that class:: 


Pcm’ 七 -Povjci -to stav-t 七 he 
MusidScwcv a^cl a dopy o-P 
the P\ro. JUhi*t v/oh ’ 七 




take daire o( -that -Pov you, 
unless you Bdd todc. -Po\r -tha-t 

m*to sctUpO. 


•m youv dasspativ 

will pHh-t a 
doi 4 \r tacM icsi ii 
n Sih<ic -this cl^ss 

has Ohly Ohc icsi, 

you 3 d: a sih 3 l c dot 


I File Edit Window Help 


hfsd> java -cp iunit.jar;. org.junit.runner.JUnitCore 




headfirst.sd.chapter7.TestRemoteReader 


l{ 0r is JU^S 

uhdc\rs-tatcd way of 
saying all the tests v-a^ 



JUnit version 4.3. 


Time : 0.321 


OK (1 test) 


hfsd> 



瓜 d hc\rcs what Bca-tBox ?yo 
looks like a-Ptcv- the test has ^ U h. 

Chcdkm3\rks v/hc\rc "thcyVc 
supposed -to be 3hd the icsi 
message is *m the log. 


With a framework in place, you can easily add the other tests from page 246. 
Just add more test methods and annotate them with @Test. You can then 
run your test classes and watch the results. 
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continuous integration 


WouldiVt it be dreamy if there was a tool that ran all 
my tests for me, every time I checked in code, so I 
wouldn’t be embarrassed in front of my team? 


Continuous integration tools run your tests 
when you check w your code 

We’ve already got a version control tool that keeps track of 
our code, and now we’ve got a set of automated tests. We just 
need a way to tie these two systems together. There are version 
control tools (or applications that integrate with version 
control tools) that will compile your code, run your automated 
tests, and even display and mail out reports — as soon as you 
(or Bob) commit code into your repository. 

This is all part of continuous integration (Cl), and it looks 
like this: 



SSI# 


(§) The version control tool notifies 
your Cl tool that there’s new code 




fo\r you avxd your 七 ca 〜 

6o^ol ? vo6CSS YOU 

alvcadv V^avc. You start out 
bY some dodod 



(l) Bob checks in some code. 





cohtlrol SCV-V L 

docs 
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testing and continuous integration 


f ；； t U ° US 釙 d build “ 

(s) The Cl tool checks out the new code, compiles it, and runs 
all your tests. Most build tools create web pages and emails 
to let everyone know how the builds are going. 




Thc *tU 3 about 

co^ol 3hd qi js 

tha \ ihc Y without 

? U vih 9 ^ do 扣 

! is fl! 9 oih 9 ^ -the 

hood. 


TV\'»s favt'^ulav bu'»ld W 

•,s tailed CWcC” 
ihcrc avc lo*ts ok sW，lav 



Dumb Questions 

Does Cl have to build and test my code every 
time I check it in? My project is so large that could 
really slow things down. 

No, definitely not. Although building and running your 
tests every time you commit changes to version control 
is a good practice, sometimes it’s not entirely practical. If 
you have a really large set of tests that use significant 
computing resources, you might want to schedule things a 
bit differently. 


Continuous 


integration wraps 


version 


control ， 
compilation ， anct 
testing into a single 
repeatable process. 
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setting up continuous integration 


At the wheel of Cl with CruiscCowtrol 

The three main jobs of a GI tool are to get a version of the code from 
your repository, build that code, and then run a suite of tests against 
it. To give you a flavor of how GI is set up, let’s take a look at how that 
works in GruiseGontrol: 


o Add your JUnit test suite to your Ant build 

Before you build your GruiseGontrol project, you need to add you 
JUnit tests into your Ant build file. 


You last sa>w ^ 


〈target name 二 "test" depends="compile"> 

<junit> 

〈classpath refid="classpath.test 〃 /> 
〈formatter type="brief 〃 usefile="false 
<batchtest> 


> 


Y\t^i 乙 ailed 

u *tcs-t w that depends 

oy\ W 6 ompile” 
-tav-jet having -f'mislicd 
su^^css-fully 


<fileset dir="${tst-dir }〃 includes^^/Test* . class 




</batchtest> 
</junit> 
</target> 


弋 tWs 士代从〜以 AlU tKe .lasses ^ 

V 一七 U ： k—d 7 。七 a: auH 

Lciutcd as JU^»t tests. No U you to tacM 

ov\t rndWidually* 


〈target name="all" depends= ,, test l 




❺ 


build, and ics-t cvc\ryili'mg. w 

Create your CruiseControl project 

The next step is to create a GruiseGontrol project and begin to define your 
build and test process. 


<cruisecontrol> 

〈project name=’’BeatBox" buildafterfailed="true"> 

<!-- This is where the rest of your project configuration will 


</proj ect> 今 


The pirojcti tag bounds all o( 

</cruisecontrol> ^ ^ i，S ^*'5^0^ 


^ iht same as ih ⑽吓七 this s^viPl J 
describes what is goihg be do^e, dnd wheh. 


jay'mg Compile, 


--> 
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testing and continuous integration 


o Check to see if there have been any changes in the repository 

Inside your GruiseGontrol project you can describe where to get your code from and 
then what to do with it. In this case, code changes are grabbed from your subversion 
repository. If the code has changed, then a full build is run; otherwise the scheduled 
build is skipped. 


tells \rcposiiov-y b> 七 

lo^a dopy b> see i-P \i actually heeds to build 乩 — 
ih o\r hot , J 


<modif i cat ions et quietperiod= ,, 10 ,, > 



,,cve you dctlavc \oca\ topy arui 
vemo-tc vefosi-tovy -to cMtck a^amst \or 


<svn LocalWorkingCopy="hfsd/chapter7/cc" f 

RepositoryLocation=”file:///c:/Users/Develope^VDesktop/SVNRepo/BeatBox/trunkV> 

</modificationset> 



Schedule the build 

Finally, you describe how often you want your continuous integration build to take place. 
In GruiseGontrol this is done with the schedule tag, inside of which you describe the 
type of build that you want to perform. 
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tests only cover what you tell them to 


Testing guarantees things will work... right? 

Version control, GI, test frameworks, build tools...you’ve come a long way since it 
was you and your college buddies hacking away on laptops in your garage. With 
all your testing, you should be confident showing the customer what you’ve built: 



I 










File Edit Window Help WhatNow? 


hfsd> java -cp . headfirst.sd.chapter".BeatBox Tracey 
got an object from server 
class j ava.lang.String 
got an object from server 
class java.lang.String 

Exception in thread ''AWT-EventQueue-0^ java.lang.ArrayIndexOutOfBoundsException 
at headfirst.sd.chapter7.BeatBox.changeSequence(BeatBox.java : 340) 

at headfirst.sd.chapter7.BeatBox$MyListSelectionListener.valueChanged(BeatBox.java:283) 
at javax.swing.JList.fireSelectionValueChanged(Unknown Source) 
at javax.swing.JList$ListSelectionHandler.valueChanged(Unknown Source) 
at javax.swina.DefaultListSelectionModel.fireValueChanaed(Unknown Source) 
at javax.swii g.DefaultL^gJ Zhang 

at javax.swii 
at javax.swiil 


at iavax.swir 


ava.awt.C 


avax.swii 


二恧 iiSi_ 


Open 


l!ggss|ssss||Sao 

fsifsisssss 餵 ! _ 


message m 
idk 


This is really starting to get old., 
can’t you get anything right? 


sf rt ou*t oy>*fco do 灼 sole wmdov/. 
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testing and continuous integration 


Here’s the code we changed in Chapter 6. The bug has to be related to this stuff 
somewhere. Find the bug that bit us this time. 


the 

todt wc 

mo di-Picd -Pv-orn 

build^U |0 

method- 


TWis \wcv- 
tlass \S ^v-om 

-too- 


What went wrong in this code? 


public void buildGUI() { 

// code from buildGUI 

JButton sendlt = new JButton (''sendlt ’’）； 

sendlt•addActionListener(new MySendListener ())； 

buttonBox.add(sendlt); 

JButton sendPoke = new JButton (、'Send Poke"); 
sendPoke.addActionListener(new MyPokeListener ())； 
buttonBox.add(sendPoke); 

userMessage = new JTextField(); 
buttonBox.add(userMessage); 

// more code in buildGUI() 


public class MyPokeListener implements ActionListener 
public void actionPerformed(ActionEvent a) { 

// We"11 create an empty state array here 

boolean[] checkboxState = new boolean[255]; 
try { 

out.writeObject(POKE_START_SEQUENCE); 
out.writeObject(checkboxState); 

} catch (Exception ex) { 

System, out .println (''Failed to poke!"); } 


// other code in BeatBoxFinal.j ava 





Why didn’t our tests catch this? 


What would you do differently? 
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tested code is completed code 



E^GRctSe 


Here’s the code we changed in Chapter 6. The bug has to be related to this stuff somewhere. 
Find the bug that bit us this time. 


public void buildGUI() { 

// code from buildGUI 

JButton sendlt = new JButton(' 、 sendIt ’’）； 

sendlt •addActionListener(new MySendListener()); 

buttonBox.add(sendlt); 

JButton sendPoke = new JButton (''Send Poke"); 
sendPoke.addActionListener(new MyPokeListener()); 
buttonBox.add(sendPoke); 

userMessage = new JTextField(); 
buttonBox.add(userMessage); 

// more code in buildGUI() 


public class MyPokeListener implements ActionListener 
public void actionPerformed(ActionEvent a) { 

// We A 11 create an empty state array here 

boolean [] checkboxState = new boolean [255^?^^^ 
try { 

out • writeObject(POKE_START_SEQUENCE); 
out.writeObject(checkboxState); 

} catch (Exception ex) { 

System, out .println (''Failed to poke!"); } 


trtdkt 

booled^s mstcad 


// other code in BeatBoxFinal•java 


. 办 d lr?k. . 

Why didn't our tests catch this? ^ uv， ^s-b valid av-v-ays h> ou\r \rcdcivcv- todt, bu*t >/c did^-t \rcally icsi 

ihc .^U| .si^C ,ojc _ihc ap.plidaiioir\ : . 

What would you do differently? ^.4.?..^y. .i?. 知 .. . 作 . P. 

da^d.h .thi 冬 •• .y/.bpii. else .aye.y/c. missihgf ). 
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testing and continuous integration 





Your code’s 
not finisked until 


J Wait. This is code from a while back. We ^ 、 

[ could write tests forever and never come j 

(up with everything. And when do we get to < 

V go back to work on developing new code? j 

0 V That burn-down rate is gonna kill us... J 

Code that doesn’t work isn’t complete! 

Complete code is working code. Not many people will 
pay you to write code that doesn’t do what it’s supposed to. 
Writing tests is very much a part of getting your work done. 
In fact, tests let you know when you’ve written the code you 
meant to write, and when it does what it’s supposed to do. 

But how many tests do you need? Well, it becomes a 
trade-off between how much of the code you test versus 
how likely are you to find a bug in the part you haven’t 
tested. A hundred tests that all test the same 50-line method 
in a 100,000-line system isn’t going to give you much 
confidence — that leaves a whopping 99,950 lines of untested 
code, no matter how many tests you’ve written. 

Instead of talking about number of tests, it’s better to think 
about code coverage: what percentage of your code are 
your tests actually testing? 


it passes its tests. 

You should be writing your tests 
to make sure your code does 
what it’s supposed to. If you 
don’t have a test for a certain 
piece of functionality, how 
do you know your code really 
implements that functionality? 
And if you do have a test and 
it’s not passing, your code 
doesn’t work. 


Hmm...lemme guess, there's a tool that we can tie 
into our process that checks this for us, right? 


Tools are your friends. 

Tools and frameworks can’t do your work for you, 
but they can make it easier for you to get to your 
work — and figure out what you should be working 
on. Code coverage is no different. 
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putting code to the test 



en your pencil 


Below is some code from the BeatBox Pro application. Your job is 
to come up with tests to get 1 00% coverage on this code... or as 
close to it as you can get. 


public class RemoteReader implements Runnable 
boolean[] checkboxState = null; 

String nameToShow = null; 

Object obj = null; 


is Codt 七 
*tKc ay\d 

poke as v/cll 

ds hovmal messages. 



public void run() { 

try { 

while ( (obj = in.readObject()) != null) { 

System, out .print In (''got an obj ect from server") 
System.out.printIn(obj.getClass()); 

String nameToShow = (String) obj; 

=(boolean[]) in.readObj ect(); 




if (nameToShow.equals(PICTURE_START_SEQUENCE)) 
receiveJPEG(); 

} else { 

if (nameToShow.equals(POKE_START_SEQUENCE)) { 

playPoke(); 

nameToShow = ''Hey! Pay attention . ^ ; 



otherSeqsMap.put(nameToShow^ checkboxState) 
listVector.add(nameToShow); 
incomingList.setListData(listVector); 

// now reset the sequence to be this 


} // close while 
catch (Exception ex) 
ex.printStackTrace(); 





} // close run 
// close inner class 



Civile 从从 

youv *tcs*U do^*t 
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testing and continuous integration 


Write a test to exercise this section of the code (pseudocode is fine). 



❺ 


Write a test to exercise this section of the code. 


^7 

Some o( these 
tests r^ay test 

你 just -the 

scd*tioh o-f dodc 

b\r adketed 一 y/Vitc 

^otes ihd’wtmg 
what else youv- 
tests cxcmdisc. 




Write a test to exercise this section of the code. 



Did we get 100% coverage? What else would you test? How? 
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100% coverage 


r^|j^rpen your pei 


ncil 
Solution 


Below is some code from the BeatBox Pro application. Your job 
was to come up with tests to get 1 00% coverage on this code...or 
as close to it as you can get. 


public class RemoteReader imp 1 err 
boolean [ ] checkboxState = null 
String nameToShow = null; 
Object obj = null; 


public void run () 
try { 

while ((obj = 




All *tWcc <^f 

-tests 

toVCV" Codt 
bc-fovc 




P =^^== SSage () thrQWS IOException { 

chec kb oiLate^oTft r \\ e ^ — [2• 

checkboxState[5] = true; 
checkboxState[19] = true; 

mOutStream.writeObject (''This is a 
mOutStrea m .w r iteOb j ect(chec k bo"state )； 


in. realdObJ ec^H 



ot 


System.out.print. 

System.out.printlhJobj.getCl 
String nameToShow = '(String) 
checkboxState = (boplean[]) 

if (nameToShow.equal 
receiveJPEG (), 

} else { 


an object from server") 



l 



PU ^^r Qld testPlctureMessa ge () throws IOExcepti. 
mOutStream.wnteObject (PICTURE—START—SEQUENCE); 
mOutStream.writeObject(EMPTY CHECKBOXES) - 
sendJPEG(TEST_JPEG_FILENAME)7 


ion 


if (nameToShow.equal^(POKE^TART SEQUEN 
playPoke(); 

nameToShow = ''Hey \ Pay attent 

} 



otherSeqsMap.put(nameToShow, 
listVector.add(nameToSh6^); 


c 


Test 

public void testPoke()throws 工 OException { 
mOutStream.writeObject(POKE_START_SEQUENCE); 
mOutStream.writeObject(EMPTY CHECKBOXES); 


incomingList. setListData (SListVecror ) 
// now reset the sequence/to be this 

} 

} // close while 
} catch (Exception ex) { 
ex.printStackTrace (); 

} 

} // close run 
// close inner class 




TW»S test multiple 

o-f todc- k 心七， mos-H ： es-b artY\t 
.sola-tcd -to just a ^ Imcs, cvc: 
-tKou^ \i be i\\t o^ly test 
•tha 七 Covers tKosc Imcs. 


o 



Did we get 100% coverage? What else you test? How? 

IVlc todt, so y\ttd *to 

d\rca*tc si*tua*tio^s. IVlc also did / 七 *tcs*t j^UI a*t 

all—would *takc someone playm^ wi-th -the 
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testing and continuous integration 


Standup meeting 



Ok, so if we test every 
single method, well have 
100% coverage, right? 


Mark: No, I don’t think so; running every method doesn’t mean 
every line of each method will run. We need to have different kinds 
of tests to get to all the different error conditions and branches. 

Laura: Wow...so I guess every variation of every method should have 
a separate test? 

Bob: But how are we going to do all that? We’ll have to make up all 
kinds of bogus data to get every weird error condition. That could 
take forever... 


Mark: And that’s not all. We’ve got to try things like pulling the 
network plug at some point to test what happens if the network goes 
down and I/O problems crop up. 

Bob: You don’t think that’s going a little too far? 

Mark: Well, if we want to catch all of the corner cases and every bit 
of exception handling". 

Laura: But a lot of that stuff never really happens... 

Bob: Then why did I bother to write all that exception-handling 
code? I’ve got all kinds of logging and reconnection code in my 
methods. Now you’re saying I didn’t need to write that? 

Mark: You did, but — 

Laura: This is impossible! 
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using a coverage report 


Testing all your code means 
testing EVERY PRANCH 

Some of the easiest areas to miss are methods or code that 
have lots of branches. Suppose you’ve got login code like this: 


public class ComplexCode { 

public class UserCredentials { 
private String mToken; 

UserCredentials(String token) 
mToken = token; 

} 

public String getUserToken() 


return mToken 



Le Ws - data to 

attcss 

YoJW y\ttd lots o( -tcs-ts (or 

this method. Ot\t v/rth a valid 
USC\nr>arwC dKui passv/ov-d— 


public UserCredentials login(String userid. String password) { 
if (userid — null) { 

throw new IllegalArgumentException (''userid cannot be null"); 

} ■■— … y/hcv-c the use\rld is null... 

if (password == null) { 

throw new IllegalArgumentException (''password cannot be null ’’）； ^~~p 

User user = f indUserByldAndPassword (userid, password) ; 0 vd \s ^ull- 

if (user != null) { 

return new UserCredentials(generateToken(userid, password. 

Calendar•getInstance()•getTimelnMillis())); 

} 

throw new RuntimeException (''Can A t find user : 、' + userid) ; 

} … OhC whc\rc the 

us^r|d ish 七 hull bu 七 
•sh't a valid (p... 

private User findUserByldAndPassword(String userid. String password) 

// code here only used by class internals 

: __ ge _ 

long nonce) { 

// utility method used only by this class 


… d 灼 dl or\C 

uscv^3rwC is 
valid bu 七 
\j>3ssy/o\rd is 



/\r^d art pv-iva*tc 

mc*t^oas...Wc 払 esc 
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testing and continuous integration 


Use a coverage report to see what's covered 

Most coverage tools — especially ones like GruiseGontrol that integrate 
with other Cl and version control tools — can generate a report telling 
you how much of your code is covered. 

Here’s a report for testing the Comp 1 exCode class on the last page, and 
providing a valid username and password: 


Code Complexity bdsi^ally tells us 
how paths thcv-c 

^ though a givch class's code, 
dvc lo*ts o-P dohdrtioholls 
to\nxy[\Caicd Codt), -this 
humbev- will be high. 



•色 Cpvtfagi-Report - Windows lnl«n«t bipbref 

_ p 厂 C^lhm^OwrlspirrtiyTOifirspafMVHf^n^Bral^raiV^lwirtdirtindpvJiirml 

B ui r ^4 ^ Kqi 償 t 


吻 |xl | 刁 

fi * El 



P 


l r£nsc / 




Cuvk^rdyi^ Hupuirl - ir^t.Ml.ulidjilur? 


Packaac f 

# Classes 

HeiAdf>rct,! ； dnCKa[»flr7 

4 


headflrst.&d.cho pier? 

classes 

Conale - Cgda 
Cpmfilf vTr^rv ■fJCMWfiJ 
User 


LJnc CoiveiMoe 

: ^ n 


Branch CQveraoe 

50^ 


in this FAckftgc ； 

OarnDlexCjQde 

Line Cwcm gc 

1 1% [ 

^f\n4 

■ 

HriCfk 扣 IC S ysflU 加 ntifl 



_ 

Cwnulc? ； Trvi> 

丄 W、[ 



u^er 4. 

&2% 

• 3?U 



Ur«nch 

1〜| 

iva[ 

I^a[ 

h / a [ 


i jjjp 


CH>IHF]-ICX>ilV 


(JcmpIcKrty 


N/A 


ti/A 


fUA 


Report genofabMf by C^bt^ura 1.9- an 9/23^07 11:0D PH. 


\S 


UcM tlass \s listed rndwidualb/ 

(kv-okcirv uf by 0v\t mcasuv-c o( -testmg 

doway is Imc doveva<\g--what 
pcv-^c^-tajc o( -the -fco-fcal Imes 
o( Code av-c v/c c 乂 
•thv-oujli ouv- -tes-ts? 


^o^cv measure 
(\Jfs, c\scs, cU) 

ViC 


So the above test manages to test 62% of the User class, 71 % of the 
ComplexCode class, and 75% of UserCredentials. Things get a lot 
better if you add in all the failure cases described on page 264. 


r.flwprpkqs 1 R^pnrt hpiidnr%r.>iri.nhnpJpr7 


Add *m -the -failuv-c ddses and wcVc 

’m rwudh bcitc\r shape with the 
Complc^Codc dass. Still heed v/ov-k oy\ 
ihc Usc\r dlass ibouah... 


PArkfliQi 1 - 


1 mr t ： irop«fgr 

he-r.rlfifirt. wl.cMoter/ 

-3 

^mf4n 

□ 




Cl^a-b--H^ In tiii^ Pdi.lkd4|i: 

Cwnc'k^C^J'C 

CampIg^Teets 

Usrr 
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the cost of testing 


Are you kidding me? All that testing, 
and were still not at 100%? How could 
you ever do this on a real project? 


O 


0 



Good testing takes lots of time. 

In general, it’s not practical to always hit 100% coverage. 
You’ll get diminishing returns on your testing after a certain 
point. For most projects, aim for about 85%— 90% coverage. 
More often than not, it’s just not possible to tease out that 
last 10%— 15% of coverage. In other cases, it’s possible but 
just far too much work to be worth the trouble. 

You should decide on a coverage goal on a per-project, 
and sometimes even a per-class, basis. Shoot for a certain 
percentage when you first start, say 80%, and then keep 
track of the number of bugs found, first using your tests, 
and then after you release your code. If you get more bugs 
back after you release your code than you’re comfortable 
with, then increase your coverage requirement by 5% or so. 

Keep track of your numbers again. What’s the ratio 
between bugs found by your testing versus bugs found 
after release? At some point you’ll see that increasing your 
coverage percentage is taking a long time, but not really 
increasing the number of bugs you find internally. When 
you hit that point, then back off a little and know you’ve 
found a good balance. 


How do coverage tools work? 

There are basically three approaches 
coverage tools can take: 

1. They can inspect the code during 
compilation time 

2. They can inspect it after compilation, 
or 

3. They can run in a customized 
environment (JVM) 



We want to try doing coverage 
analysis on our project, but right now our 
tests cover hardly anything. How do we 
get started? 

Start small. Set your target at 10%. 

Then when you hit it, celebrate, then bump 
it to 15%. If you’ve never done automated 
testing on your project before, you might find 
that some parts of your system are really hard 
to automate. We’ll talk more about that in 
Chapter 8. Get as far as you can, though— 
some testing is way better than no testing. 


Don’t you end up with a lot of test 

code? 

Absolutely. You’ll have a 2-to-1 or 
3-to-1 test-to-production code ratio if you’re 
really doing good testing. But finding bugs 
early is so much easier than having your 
customer find them. It's more code to 
maintain, but if your environment is in place, 
the extra code and effort is generally worth 
the trade-off. More satisfied customers, more 
business, and more money! 
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testing and continuous integration 


ftettmg good coverage isn't always easy. 

Now that we’ve gotten our heads around coverage, let’s look 
back at BeatBox Pro. Now that we know what to look for, 
there are all kinds of things not being tested: 


卜 r” > Wt vcally 

1 tf 卜呦 J this 乙 。 d J 

I h，S ^-too bad io 
though s，ue ihe^res ho veal 

r™ Si f ^ou 9 h ; so iUai will 
take some time. 



/rrrr^\ 


We do/ 七 have a^y ^U| ^ 
*tcs*t dodc • v/hidh is hov/ y/c 
missed latest BeatBox. 
P\ro bu^ m 七 he dus-tomcv 
demo- 


TV\csc av-c ovav 

a 〜、 6aW 

Wcvc some toAt 

^ Ust tV>c rtu^ ^ 


/ rrrre^ \ 


Ustm^odc, c^cv. Uts 

o( MlPl^ ot C c as ^ 

to 


There are some things that are just inherently hard to test. GUIs actually 
aren’t impossible; there are tools available that can simulate button clicks and 
keyboard input. Things like audio or 3-D graphics, though, those are tough. The 
answer? Get a real person to try things out. Software tests can’t cover all the 
different variations of an animated game or audio in a music program. 

So what about code you just can’t seem to reach? Private methods, third-party 
libraries, or maybe your own code that’s abstracted away from the inputs and 
outputs of your main interface modules? Well, we’ll get to that in just a few more 
pages, in Chapter 8. 

And then...enter test-driven development. 
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is 100% coverage efficient? 




w mmM 「 w p ■ ，圓 ■ 


Check off all of the things you should do to get 
good coverage when testing. 


Test the success cases ("happy paths”). 

Test failure cases. 

Stage known input data if your system uses a database so you can test 
various backend problems. 

Read through the code you’re testing. 

Review your requirements and user stories to see what the system is 
supposed to do. 

Test external failure conditions, like network outages or people shutting 
down their web browsers. 

Test for security problems like SQL injection or cross-site scripting (XSS). 

Simulate a disk-full condition. 

Simulate high-load scenarios. 

Use different operating systems, platforms, and browsers. 


► Answers on pa^e 272. 
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testing and continuous integration 


Standup meeting 



Laura: I really wish we knew all this going in...before we started doing 
demos with the customer. 

Bob: Yeah, I could have run tests on my code, and known I’d screwed up the 
other user story when I got mine to work. Anything to get us to full coverage... 

Mark: Whoa, I’m not sure full coverage is reasonable. You ever heard of the 
80/20 rule? Why spend all our time on a tiny bit of the code that probably 
won’t ever get run? 

Bob: Well, I’m going for 100%. I figure with another few days of writing 
tests, I can get there. 

Mark: A few days^ We don’t have time for that; don’t you have a lot of 
GUI code to work on? 


Laura: I agree. But I’m not sure we can even get to 80% coverage: there’s a 
lot of complex code buried pretty deep in the GUI, and I’m not sure how to 
write tests to get to all of that stuff. 


Mark: Hmmm...what about 50%? We could start there, and then add tests 
for things we think are missing. The coverage report will tell us what we’re 
missing, right? 


Bob: Yeah, we can look at which methods we’re not calling. If we could hit 
every method, and then test the edge cases on code that’s used a lot, that’s 
pretty good... 

Laura: Sounds like a plan...You just committed some stuff, right? I’ll check 
the coverage report as soon as GruiseGontrol finishes its build. 
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Lets you create a repository to keep your code in a secure place. 


Lets multiple people check out copies of the code and work 
efficiently as a team. 

Lets multiple people check changes back into the repository and 

distribute them to the rest of the team. 

Keeps track of who changes what, when, and why. 

Branches and tags code so you can find and change versions of code 
from way back when. 

Rolls back changes that never should have happened in the first place. 


Makes sure your code compiles. 



Tests your code. 

. 卜） 

Tells us how well we’re testing. J You vc Jo-ttch a Couple of -these 

you\r ChVivohruCh-t ho\ 

with a ^ohtihuous ihtcgv-atioh iool 

and what version control doesn’t do 


^uiL yuui undu coiiipilLS 


-Teato code. 



I j Thinks for you. 

I j Makes sure your code is readable and well-written. 


iron merit 


for testing 



your ewvirowmewt 

What^i iiiiui i^Ul.! l 1 ul does 
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testing and continuous integration 




Testcposs 


Take some time to sit back and test the right side 
of your brain (get it?). 



Across 

5. The practice of automatically building and testing your code 
on each commit. 

7. This should fail if a test doesn't pass. 

8. Instead of running your tests by hand, use. 

10. Coverage tells you how much .you're actually 

testing. 

11. When white box testing you want to exercise each of 
these. 

12. Ability to be climbed - or support a lot of users. 

13. 3 lines of this to 1 line of production isn't crazy. 


Down 

1 ■ Just slightly outside the valid range, this case can be bad 
news. 

2. All of your functional testing ties back to these. 

3. Peeking under the covers a little, you might check out some 
DB tables when you use this kind of testing. 

4. 85% of this and you're doing ok. 

6. Continuous integration watches this to know when things 
change. 

7. Test the system like a user and forget how it works inside. 

9. You're done when all your. 
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exercise solutions 



your pencil 
Solution 












Check off all of the things you should do to get 
good coverage when testing. 


s/\ Test the success cases ("happy paths”). 


Test failure cases. 


Stage known input data if your system uses a database so you can test 
various backend problems. 


Read through the code you’re testing. 


Review your requirements and user stories to see what the system is 
supposed to do. 

Test external failure conditions, like network outages or people shutting 
down their web browsers. 


Test for security problems like SQL injection or cross-site scripting (XSS). 


Simulate a disk-full condition. 


Simulate high-load scenarios. 


Use different operating systems, platforms, and browsers. 


ot\ youv app, al,! of these av-c d\ri*ti£-al 
^ood tests. But, *1+ you vc usm3 a 
tool you out y/hev-c you mi 吵七 

be -bests part d youv system. 


* p 
*to yttm 
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testing and continuous integration 



Testeross Solution 
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you/* so 疗 ware development toolbox 



Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter, 
you learned about several techniques to keep you 
on track. For a complete list of tools in the book, 
see Appendix ii. 


tascs 


Development 


細⑽ v^s you, 

s 7 st^, you r^ttd {p all 

V^as bo auo^i -for suctss 
as well as -failure tascs 

AuWatc 七—▲州 ^ — Wc 

Use a 6oy\tmuous *m*tc5V"a*t»or\ *tool *to 
—W“dT— 七 ㈣ 7 一 如 

OY\ eaA 


如 Some 

key 

you leaded ih 
^haptcir... 


..arvd so«>c 

r .m6 咖 bcWmd 


^jg& ^Ch 七 PHhdiples 


Tcs-tmg is a -tool -to let you khow wheire 

y° uv * P^jcdt is ai all times 

Cohtmuous ihtcgvatioh gives you 

to^\At^U that the dode ih y 。 冰 
^fosiWy is toYYtti ahd builds pv^op^ly 

Code dov^ge is a ^thc\t 

° + tcstih 9 ^dtiv Ch css th^h test douht 


BULLET POINTS - 

■ Using Continuous 
Integration tools means 
something is always 
watching over the quality of 
the code in the repository. 

■ Automated testing can be 

addictive. You still get to 
write code，so it’s fun. And 
sometimes you break things. 
Also fun. 

■ Make the results of your 
continuous integration builds 
and coverage reports public 
to the team— the team owns 
the project and should feel 
responsible. 

■ Have your continuous 
integration tool fail a build if 
an automated test fails. Then 
have it email the committer 
until they fix it. 

■ Testing for overall 
functionality is critical 
to declaring a project as 
working. 
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8 test-driVen development 


^Holding your code 

^accountable 



Alright John—heres what Tm expecting 
out of you ： If someone doestVt know their 
password, they don’t get in. Never heard 
of the guy? They don’t get in... 卜 




Sometimes it’s all about setting expectations. Good code needs 

to work, everyone knows that. But how do you know your code works? Even with 
unit testing, there are still parts of most code that go untested. But what if testing was a 
fundamental part of software development? What if you did everything with testing in 
mind? In this chapter, you’ll take what you know about version control, Cl, and automated 
testing and tie it all together into an environment where you can feel confident about 
fixing bugs, refactoring, and even reimplementing parts of your system. 


this is a new chapter 


test before code 


Test FIRST , wot last 

Instead of trying to retrofit testing onto an existing project, let’s look 
at a project from the ground up using a new technique, test-driven 
development, and write your code with testing in mind right from the start. 


Starbuzz Coffee has been selling gift cards for several months, but now they 
need a way to accept those gift cards as payment for their drinks. Starbuzz 
already knows how their page should look, so your job is to focus on the design 
and implementation of the gift card ordering system itself. 





4 

jid C rfte 


*， 其 _ lAr firr -- 

»« — _—-_ 一 一 —~ 

令 ■ D - # 




Starbuzz Coffee Beverages 

House Bl«nd, £1.4 & 

A mioQflh,, frrtl beef'd d tcfksM Fern dnd Gudl^fniila 

Mochs Caffe Latte, 12.35 

t&pfe&K^^earrsd mh^fidcfwioolifie 

•Cappuccino, $1.39 

A miKfcre 0( KpfesK, sleamed milt, and itiR fcMirv 

C i Tc 9 | . 3 S 

A itrtt nade wm tladt _ sptes n_ft, and Iwtey 
OACard q 



CM-thJlir I PnWtiJcd 




: usWc^ ^ usc 3 ^ 
i\\t ^ ^ kiosks rn 


Title ： 


Reorder your cof fee 

with a gift card 

_sssiis: 

- n, ^r^uyrorpfckjp, 

4 - 


Lt{!s s*ta\rt 
七 Vus … 


Task I 

Caytu^rc O^rdcv ih-fo ； 
(a<rd iivfo, a hC | 
收中 i ih 4 . 


ask 


z 

w'Ch't business 
"to fv-odcss airtd 
ordev-s. 


Task3 

mnedt ovdev- 
■odcssov* bo v/cb site- 
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test-driven development 


So weVc goiwg to test FIRST 



The Starbuzz Gift Cards story is broken down into tasks, so if 
we’re going to test first, we need to begin by looking at our first 
task, which is capturing information about orders, gift cards, and 
receipts. Remember, if we jump right into code, we’ll end up right 
back where we did in the last few chapters... 


Analyze the task 


First break down the task. For this task you’ll need to. 


I . a 。 alert: VstoW m 伙仪“奶 


Represent the order information. You need to capture the 
customer’s name, the drink description, the store number the customer 
wants to pick up the drink from, and a gift card number. 

Represent gift card information. You need to capture the 
activation date, the expiration date, and the remaining balance. 

Represent receipt information. You need to capture the 
confirmation number and the pickup time, as well as the remaining 
balance on a gift card. 



Usually, -tasks av*e 
just 0he thihg, but 
■the -th\rcc itcrhS 
,h 仏 s i^sk a\rc so 

加 all, thcyVc easier 

^ca-t as a si^le 
of wo^k. 


Write the test BEFORE any other code 


We’re testing first, remember? That means you have to actually write a test... first. 
Start with the order information part of the task. Now, using your test framework, 
you need to write a test for that functionality. 个 




Welcome to tcst-drivgw devdopmewt 


以⑽ 个气上二二一 

Cl ?^^ sscs - 


When you’re writing tests before any code, and then letting those tests 
drive your code, you’re using test-driven development, or TDD. 
That’s just a formal term to describe the process of testing from the outset 
of development — and writing every line of code specifically as a response 
to your tests. Turn the page for a lot more on TDD. 
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unit testing 


Your first test... 

The first step in writing a test is to figure out what exactly it 
is you should be testing. Since this is testing at a really fine¬ 
grained level — unit testing ~you should start small. What’s 
the smallest test you could write that uses the order 
information you’ve got to store as part of the first task? Well, 
that’s just creating the object itself, right? Here’s how to test 
creating a new Order In format ion object: 


is ^ 氣 i 七 
㈣ ...a si h al c 

■/■kji. i I 



package headfirst.sd.chapter8; 
import org.j unit.^; 

public class TestOrderlnformation { 

@Test 

public void testCreateOrderlnformation() { 

Orderlnformation orderlnfo = new Orderlnformation(); 

} 




Wait—what are you doing? There's no way this 
test is going to work; ifs not even going to compile. 
You re just making up class names that don’t exist. 
Where did you get Orderlnf ormation from? 


Youre exactly r!gk! We’re writing 

tests first, remember? We have no code. There’s no way 
this test could (or should) pass the first time through. In fact, 
this test won’t even compile, and that’s OK, too. We’ll fix it 
in a minute. The point here is that at first, your test... 


278 Chapter 8 




test-driven development 


.fails miserably. 


Unlike pretty much everything else in life, in TDD you want your tests 
to fail when you first write them. The point of a test is to establish 
a measurable success — and in this case, that measure is a compiling 
Order Informat ion object that you can instantiate. And, because you’ve got 
a failing test, now it’s clear what you have to do to make sure that test passes. 



Rule #1 ： Your test skoulct always 
FAIL tefore you implement any cocte. 


The f ^ ^ 
wc^-tivc ies-t- 



NOW write code to 
get the test to pass. 

You’ve got a failing test...but that’s 
OK. Before going any further, 
either writing more tests or working 
on the task, write the simplest 
code possible to get just this 
test to pass. And right now, the 
test won’t even compile! 

? oss\Wc yet ； ^ you 

\y\j "to domfuc- 


File Edit Window Help 


hfsd> javac -cp junit.jar 

headfirst.sd.chapter8.TestOrderlnformation.java 

TestOrderInformation.java : 8 : cannot find symbol 

symbol : class OrderInformation 

location : class headfirst.sd.chapter8•TestOrderInformation 
OrderInformation orderlnfo = new Orderlnformation(); 


TestOrderInformation.java : 8 : cannot find symbol 
symbol : class Orderlnformation 

location : class headfirst.sd.chapter8•TestOrderInformation 
Orderlnformation orderlnfo = new Orderlnformation(); 

A 

2 errors 


hfsd> 


喝 a— 


your pencil 


We have a failing test that we need to get to pass. What’s the 
simplest thing you can do to get this test passing? 
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green means pass 


fret your tests to ftREEN 

The only goal you should have at this point is to get your test 
to pass. So write just the code you have to in order for your test to 
pass; that ? s called gettingyour tests to green. 


public class Orderlnformation 


6frttr\ v-c-fcv-s *to *biic bav - 七七 
JU^iVs ^U| displays 4 ⑼ all tests pass, 
a^y test bailed, it displays a rtd bar. 


ttc\rc's the UML (or -the 
^lass. /Vo attv-ibutes, y\o methods— 
jus-t 3v) empty dlass. 






Yes, that’s it. An empty class. Now try running your test again: 


File Edit Window Help Class 


hfsd> javac -d bin -cp junit.jar *.java 

hfsd> java -cp junit.jar;.\bin org.junit•runner• 
JUnitCore headfirst.sd.chapter8.TestOrderInformation 

JUnit version 4.4 



hfsd> 


The "test Compiles 
as docs -the 

Olrdcir/h-foirma-tioh class. 



With this test passing, you’re ready to write the next test, still 
focusing on your first task. That’s it~you’ve just made it through 
your first round of test-driven development. Remember, the goal 
was to write just the code you needed to get that test to pass. 



Rule #2: Implement tke 

SIMPLEST CODE POSSIBLE 

to make your tests pass* 


280 


Chapter 8 



















test-driven development 



O 


Seriously? You made an empty class to get a test 
to pass and you call that SUCCESS? 


Test-driven development is about 
doing the simplest thing you can to 
get your test to pass. 

Resist the urge to add anything you might need in the 
future. If you need that something later, you’ll write 
a test then and the code to pass that test. In the 
meantime, leave it alone. Obviously you can’t stop 
here — you need to move on to the next test — but 
focusing on small bits of code is the heart and 
soul of test-driven development. 


—a Need It. 


• ft 


Red, greew, refactor 

Test-driven development works on a very simple cycle: 


r 


O 


❻ 


Red ： Your test fails. 

First you write a test that checks whatever functionality you’re about to 
write. Obviously it fails, since you haven’t implemented the functionality 
yet. This is the red stage, since your test GUI probably shows the test 
in red (failing). 


Green : Your test passes. 

Next, implement the functionality to get that test to pass. That’s it. No 
more. Nothing fancy. Write the simplest code you can to get your test 
to pass. This is the green stage. 


3。 thvough -the 乙 yde ajaih. 


Refactor : Clean up any duplication, ugliness, old code, etc. 

Finally, after your test passes, you can go back in and clean up some 
things that you may have noticed while implementing your code. This 
is the refactor stage. In the example for Starbuzz, you don’t have any 
other code to refactor, so you can go right on to the next test. 
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testing a user story J s functionality 



E%ettciSe 


Below is the task we’re working on and the user story it came from. Your job is to add the next 
test to the TestOrderinformation class to make progress on this task. 


Title: 


frcordcr your coff ec 

.wrth. Qifi* c.ft.rd 

Description ： •… 5e|ectypur coffee 

from the options, ewteryour gift card, number, 
name ； preferred store.and click submit to get a 
confirmation number, remamiwg balance, and 
estimated tiVw^ whew it 




Priority: 


20 


Task I 

Caftuvc ovdev- m-fo, 
dard m-fo, and 
v-cdci\>*t m-fo. 


Should be o” 




^vd av^d 代辦七 


import org.junit. 


★ 


public class TestOrderinformation 
@Test 

public void testCreateOrderlnformationlnstance() 

Orderlnformation orderlnfo = new Orderlnformation(); 

} 

@Test 

public void testOrderlnformation() { 


^ l-P youVc hot 3 

t\ry 如 d wv-iic ou-t 
"UiC "tes ■(: 'm "the -^v*3rwcwov*k VouVc 
usmj, ov- type ii m-to youv- IDE. 
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test-driven development 


Now implement the code to make your test pass. Remember, you just 
want the simplest code possible to get the test passing. 


O^At^c I oVrr>3*tior> dldss 
bo You *to -fill i*t 

ou 七 *to pass i\\t icsi you jus*t v/v-otc. 



public class Orderlnformation 


U ? date tV.e 0 ， de,l，WaW 
dass dia^am, W — < 
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implement a test in code 


nceRctSe 
%o L yi 


Below is the task we’re working on and the user story it came from. Your job is to add the next 
test to the TestOrderinformation class to make progress on this task. 


Title 


Preorder your coffee 

with a gif t card 

Description ： .. Se|ectyoyr c^fee 

from the options, 叫 MY 。 •叶 叫 rd 叫她 

—preferred sto^.awdcjick submit to get a 
conf irmation number, remaiwiwg balawce f awd 

esii— 研而 e whew it wil 匕 

Task I 


sWc to ovdev -Wat 


t Vt 


st 


t 


Priority: 


o 於， 


Caftuvc ovdev- m-fo, 
ddv~d m-fo, drtcl 
v-cdcift "m-fo. 


WC 


import org.junit.^; 

public class TestOrderinformation { 

@Test 

public void testCreateOrderInformationlnstance() { // existing test : 

^ —ply the 

@Test 〜广 sets ea 

public void testOrder Inf ormation () { ，^/ ^cca to tira 匕 k, dhd -thch ^hc^ks -to 

0\rdc\r I^-fo\rma*ti oy\ o\rdc\r |^-fo — OyAct I^-foma*tioir\()j SUV-C WC get the same values out. 

o\rdcv|^-fosc*tCusiomc\rKaw'c( W pa ^ > )； 

o\rdc\r|^-fo sc*tD\r*mkDcsd\rip*tioir\( w Modiia dappa - latte -- hal*f—v/hip - ski 你一 *(Vadmo ”)； 

o\rdc\r|^-fo.sc*t^i-f*tCa\rdKumbcv*0 23 午弓石)； 

ordcW Jo.SC 七 PrcWcdSWNumb 饮 ( 糾 ” /ou might io use 

asscv-tE^uaKov-dcv-l^-fo jc-tCus-bomcv-NamcO, w Da^O ； ih youv- ovm todt) so you do /七 

assc\rtE^uaKo\rdc\r|^-fo 5C*tDv-*mkPcsd\rip*tioir\0, ~ 叫 typos beweeh setting 

w Modha 匕 appa — latte — v/i*th — hal*P->wliip-ski 你一 <(Va 匕 mo w ); 泊 lues 3hd ^kdkihg a^si £he 

a 议 v^ 〜 l(c>rdcW Joyt 糾七 OdN_b 饮 0, 123 午 ㈤ ； Valu rr ^ iall Y ih 

assc\rtE^ual(ov-devIo.5C*tP\rC-fcv-\rcdS*to\rcNumbc\r(), Ohg t cc-d\rihk hames). 
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test-driven development 


Now implement the code to make your test pass. Remember, you just 
want the simplest code possible to get the test passing. 


public class Orderlnformation { 

pv-iva*tc dv-mkPcs^v-iftio ^； 

private m 七 ji-ftCav-dKumbcv -； 
pv-iva*tc m 七 pv-c-fcv-\rcdS*to\rcNumbev -； 

f>ubli£. void sc*tCus*tomc\rKaw\c(S*tv"m5 y\Sw\c) { 

匕 us*tow\CV"|Vdw\C 二灼 

} 

f>ubli^ void sc*tPv-*mkPcs^\rip*tio^(S*tv-'mg dtsc) { 

(jhr’mkDcsd\rip*tio 的二 dtsti 

} 

f>ubli^ void sc*t^i-f*tCa\rdKumbc\r(*m*b JdKum) { 

ji-ftCav-dNumbcv- =» JdNum ； 


public void sc*tPv-c*fcv-v-cdS*tov-cNumbc\r('m*b 
pv-C-fcv-\rcdS*to\rcNuw\bc\r =» 

} 

public S*tv"mj jrtCus-tomcv-KamcO { 

v-ctuv-^ dus-tomcv-Kamcj 

} 

^M\t ytPv-*mkPcs^\rip*bio^O { 

v-c*bu\nr^ d\r'mkPcs^\rip*tio ^； 

} 

public m*t Jct^i-ftCav-dKumbcv-O { 

\rc*bu\r^ ji-f*tCav-dKumbev -； 

} 

public JctPv-c-fcv-v-cdS-tov-cNumbcv-O { 

V-C*tuV-^ pv-C*fcv-\rcdS*toV-cKur»\bcv-j 


灼 um 


){ 


:㈣ 以 

如 d se “W variables. 9 1 


㈣ 雜⑼。 




Ov-dcv-| h-pov-ma-tioh 



一 dus-borwcv-Namc ： S-tv'mg 
一 dv-mkPcsdv-ip-tio^ : S-tvmj 
一 ji-P-tCav-d/Vumbcv- : m*t 
-pv-c-Pcv-v-cdS-fcov-cNumbcv- : m-t 

- - - -- 

+ sctCus-tomcv-Na^cf^amc ： S-tv'mj) 

+ sc-tDv-'mkDcsdv-ip*tio^(dcs^ : £-tv-'mg) 

+ sc-t^i-p-tCav-dNumbcv-fjdNurw : m-t) 

+ sc-tPv-c-Pcv-v-cdS-fcov-cNumbcv^um : m-t) 
+ jc-tCus-fcomcv-NamcO : S-tv-'mj 
+ jctPv-'mkDcsdv-ip-tio^O : S-tv-'mj 
+ jrt^i-p-tCav-d/Vumbcv-O : m-t 
+ jctPv-c-fcv-v-cdS-tov-cNumbcv-O : m-t 


— ^〆 
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drive your code with TDD 


Iw TPP, tests PR1VE your impkmewtatiow 

Now you’ve got a working and tested Order Inf ormat ion class. And, because of the 
latest test, you’ve got getters and setters that all work, too. In fact, the things you put in 
the class were completely driven by your tests. 

Test-driven development is different from just test-first development in that it drives your 
implementation all the way through development. By writing your tests before your 
code, you have to focus on the functionality right away. What exactly is the code you’re 
about to write actually supposed to do? 

To help keep your tests manageable and effective, there are some good habits to get into: 


Each test should verify ONLY ONE THINS 

To keep your tests straightforward and focused on what you 
need to implement, try to make each test only test one thing. In 
the Starbuzz system, each test is a method on our test class. So 
testCreateOrderlnf ormation () is an example of a test that 
only checks one thing: all it does is test creating a new order object. 
The next test, which tests multiple methods, still tests only one piece of 
functionality: that the order stores the right information within it. 




AVOID DUPLICATE test code 

You should try to avoid duplicated test code just like you’d try to avoid 
duplicated production code. Some testing frameworks have setup and 
teardown methods that let you consolidate code common to all your 
tests, and you should use those liberally. You also may need to mock up 
test objects — we’ll talk more about how to do that later in this chapter. 


Keep your tests in a MIRROR DIRECTORY of 
your source code 

Once you start using TDD on your project, you’ll write tons of 
tests. To help keep things organized, keep the tests in a separate 
directory (usually called test/) at the same level as your source 
directory, and with the same directory structure. This helps avoid 
problems with languages that assume that directories map to 
package names (like Java) while keeping your tests cases out of 
the way of your production code. This also makes things easier 
on your build files, too; all tests are in one place. 


database you 

“uld sc 七栋 a 七叶 … 7 祕 
se 七叶 ( ） method, av^d 

release 

tcavdoW) 

U 70^ itsi ^amev/ovk. 
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test-driven development 



If TDD drives my implementation, 
when do we do design? 

TDD is usually used with what’s called 
evolutionary design. Note that this doesn’t 
mean code all you want, and magically 
you’ll end up with a nicely designed system. 
The critical part of getting to a good design 
is the refactoring step in TDD. Basically 
TDD works hard to prevent overdesigning 
something. As you add functionality to 
your system, you'll be increasing the code 
base. After a while you’ll see things getting 
naturally disorganized, so after you get your 
test to pass, refactor it. Redesign it, apply 
the appropriate design patterns, whatever it 
takes. And all along your tests should keep 
passing and let you know that you haven’t 
broken anything. 

What if I need more than one class 
to implement a piece of functionality? 

That’s fine functionally, but you should 
really consider adding tests for each class 
you need to realize the functionality. If you 
add tests for each class, you’ll add a test, 
implement the code, add a test, etc., and 
build up your functionality with the red, 
green, refactor cycle. 


The test example we just did had 
us writing tests for getter and setter 
methods. I thought we weren’t supposed 
to test those. 

There’s nothing wrong with testing 
setters and getters; you just don’t get much 
bang for the buck. The setter and getter 
example was just the beginning. The next 
few pages really dig into a challenging TDD 
problem. 

So when I implement code to make 
a particular test pass, I know what the 
next test I have to write is. Can’t I just add 
the code I’m going to need for that test 
too? 

No. There’s a couple problems with 
that approach. First, it’s a really slippery 
slope once you start adding things that are 
outside of the scope of the test you’re trying 
to get to pass. You might think you need 
it, but until a test says you do, don’t tempt 
yourself. 

The second, and possibly more severe 
problem is that if you add code now for the 
next test you’re going to write, that second 
test probably won’t fail. Which means you 
don’t know that it’s actually testing what you 
think it is. You can’t be sure that it will let you 
know if the underlying code breaks. Write 
the test—then implement code for that test. 


Test-driven 
development is 
all about creating 
tests lor speciiic 
functionality, and 
tken writing code 
to satisiy tkat 
functionality. 


Anytking teyonct 
tkat iunctionality is 

NOT IMPORTANT 


to your software 
(rigflit now). 


vc Ic-ft a^sv/cvs out 

OV. tw»s ⑽叶 k 7 0lA ^ 
W 七 C 仔 CSC tests ov. 70 UV ov/L. 



ExeficiSe 


Finish up the remaining work on the current Starbuzz task 
by writing tests and then the implementation for the gift card 
and receipt objects. 
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task done when tests pass 


Completing a task means 
you've got all the tests you 
need, and they all pass 

To finish up the first task, you’ll need to be able to test that 
order, gift card, and receipt information can be captured and 
accessed. You should have created objects for all three of 
these items. Here’s how we implemented each object... 




囊歐 


QydcY'l^-fornxS-iioY) 


一 dv"m|cDes^rip 七 ion : S-tv-ihJ 
一 3i*f"tC3V"d/N/uinf»bcV" : 'mt 
一 pV-C-Pcv-\rcdS'to\rc/Vuinf»bc\r •* 'mt 

- -- - - ^ 

+ sctCuS"tonf»c\r/V3irwc(^3irwC ： S*brmj) 

+ sctDv-*mkDcsd\rip-tio^(clcsd •* S-tv-'mj) 

+ sci^i-p-tCavd/Vumbcv^Num : mi) 

+ sc-tP\rc-PcmdS-to\rcNurwbcv^urw : mi) 

+ JC-tCus-fcorwcv-ZVarwcO : S-tv-mg 

+ 5C-tDv-'mkDcsd\ripiio^0 : SVmg 

+ JC-t^i-p-tCaird/VuirwbcvO : *rni 

3ctP\rc-PcmdS-tov-c/Vumbcv-0 : mi 



Receipt 


一 ^oir\-fi\rma*tioir\Kumbc\r : *m*t 

一 pi^kupTimc ： Da*tc 


+ srtCo 灼 *fi\rma*ticrn|N/umbev* ( 灼 o : m*t) 

+ sc*tPidkupTimc(da*tc : Date) 

+ sc*t^CBala^c(bal : BigDcdimal) 

+ gc*tCoir\-fiv-ma*tio^Kumbc\rO : *m*t 

+ gctPi^kupTimcO : Pa*tc 
+ gct^CBala^dcO : BijDc^imal 


^i-f*tCa\rd 


- ad*tiva*tio^Da*tc ： Da*tc 
一 c^piv-a*tio^Da*tc ： Da*tc 
— bdld^C : 

+ 5c*tA^*tiva*tio^Da*tcO : Da-tc 
+ 5c*tE^piv-a*tioir\Da*tcO : Da*tc 
+ ytBala^dcO : BijDcdimal 
+ sctBala^cfBi^Dc^imal) ： void 
+ c<\uals(objcd*t : Object) : booled^ 
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test-driven development 


Whew your tests pass, move ow! 

The first task is complete and we have Receipt, Gif tCard, 
and Orderlnf ormation classes written and tested. Now it’s 
time to try our TDD approach on a tougher task: implementing 
the business logic to process and store orders. 



This task is no different than the last one. We’ll just follow the 
same approach. Write a test that fails, implement the code to get 
the test passing, perform any cleanup, and then repeat. 



you are here ► 


289 














first fail 


Red: write (failing) tests 

The first step is to write a test. The user story says we need to process 
and store order information, so let’s assume we’ll need a new class for 
that, called OrderProcessor: 


import org.junit. 




public class TestOrderProcessor { 

@Test 

public void testCreateOrderProcessor() { 

OrderProcessor orderProcessor = new OrderProcessor() 

} 



aboiA*b Mme 
Ov-dcv-Pv-odcssov-. Its 

just a late *to fu 七 
bus'mess lo 汐乙 ， smde 
only classes 
•m aff av-c -fov- 
s-tov-'mj da^ts. 


File Edit Window Help Failure 



As you would expect, this test will fail — 
you don’t have an OrderProcessor 
yet. So now you can fix that pretty easily. 


TVis *tcs*t docs^-t cvck\ 
tomf'ilC) lc*b alor\C pass. 


hfsd> javac -cp junit.jar 

headfirst.sd.chapter8.TestOrderProcessor.java 

TestOrderProcessor.java : 8 : cannot find symbol 
symbol : class OrderProcessor 

location : class headfirst.sd.chapter8.TestOrderProcessor 
OrderProcessor orderProcessor = new OrderProcessor() 

A 

TestOrderProcessor.java : 8 : cannot find symbol 
symbol : class OrderProcessor 

location : class headfirst.sd.chapter8.TestOrderProcessor 
OrderProcessor orderProcessor = new OrderProcessor() 

A 

2 errors 
hfsd> 


ftrecw: write code to pass tests 

To get your first test to pass, just add an empty OrderProcessor class: 

public class OrderProcessor 

} 

r File Edit Window Help Success 



"tcs*t Compiles 
passes. 


hfsd> javac -d bin -cp junit.jar *.java 


That’s it. Recompile, retest, and you’re 
back to green. The user story says 
you need to process and store order 
information. You’ve already got classes 
that represent order information (and 
a receipt), so use those now along with 
the OrderProcessor class that you 
just created. 


hfsd> java -cp junit.jar;.\bin org.junit.runner. 
JUnitCore headfirst.sd.chapter8.TestOrderProcessor 

JUnit version 4.4 

Time : 0.018 
OK (1 test) 

hfsd> 
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test-driven development 





Red 

Below is a new test method. Implement a test that will verify your 
software can process a simple order. 


N/oull -to 

-to^c-tV^cv *to 
dcs 6 v«bc *bV^c 
ovdcv... v 


// other tests 
@Test 

public void testSimpleOrder() { 

OrderProcessor orderProcessor = new OrderProcessor() 



• 3 灼 d f>dss 

it ov\ {jo 七 he 
o\rdcv- p\rodcssov 
make suvc 
i 七 wo\rkcd. 


一 £-usijon\crhl3ime : 

- dvmkDcsfiyiptio^ : 

一七 'bor: iirt 

一 fyc-fcv"\rcdS-toycNur»»bcv : m-t 

- - --^ 

+ sciCusion\erManxe(r\an>c : £iviv\^) 

+ sc-tPvnr>kPcsfiyip-tio^(dcs^ : 

+ ^i^ifiCardhlu^c^^ : \M 

+ sctPvc-fcyycd£-tovcNu^bcv^ur»> : mi) 

+ ^eiCusioimCvl^3rv\c() : 

+ 3 ctPv-'mkP«fivip-tioK >0 : 

+ 3 亡 七与 •_{ 七队 : iirt 

+ 3 ctPv-c-fcmd£WcNu^bcyO : mi 


- toir>-fiv-r»>a-tioif>Nur»>bcv* : int 
pidkufTimc : Pate 

3 匕 Baldmde : 


+ sctCoif\-fiv-ma-tio^|Vumbcv-(ino : mW 
+ sc-tPidkupTir»»c(da-tc ： Pate) 

+ sc-t^CBala^c^bal : B 13 P 必你 al) 

+ ^ctCoK\-fi\rr»»a-tioif>Nur»»bcv*0 : int 
+ ytPidkupTimeO : Pate 
^ti6\C?>d\Bv\ttO : Bi 3 pcdiw»al 


^i-f tCav-d 


- adtiva-tiomDa-tc ： Pa-tc 
- c^fiv-a-tiomPa-tc ： Date 



3 c-tA^tivatio^Patc(«^ : Pa 
+ ^ctE^iv-atio^Pa-tcO : Pa-tc 
+ ^c-tBala^cO : 

+ ： void 

:«\uals(objct-t ： Object) : boolean 
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keep it simple 



Red 

Your job was to implement a test that will verify your software can 
process a simple order. 


^ OU jus-t 

U P s damd 

—beir hcv^c... 


The simplest 
V^cvc -to y^oi ^0^7 
about tV^c V>aU6c 
tavd-. tWs 

• 1S 〆 

s_lcst vcvsio^ ok 
ovdev- ^votess'm^ 


// existing tests 
@Test 

public void testSimpleOrder() { 

// piv-si tv-ca*tc Ac Oirdcv p^rodcssov 

Ov"dcv"Pvodcssov ovdcv"Pv"odcssov — Ov^dcv'Pv'odcssovO, 

// TKcv> you y>ccd *to dcstv-ibc *tKc o\rdcv *tKa*t sKould be pladcd 
O\rdcv|^o\rmatioy> o\rdcvk*fo - ^ 0 ^rdc^r|ir>-fo\rmatioir> 0； 
ovdcv-|y\-fo sc*tCust>mCvNaw'C^ W p3^ ^ 

o\rdc\r|y>4 sctPv-'mkPcsdnptior>( W Bold v/rth iroor^); 
ovdcv-|^-fosc*t^i-f*tCav-dNumbcv-(lZ^^)i 

ovdcv-|^-fo.sc*tPvc-fcvvcdS*tovcNumbcvOZ ^)； 

// tta^d oirdcir bo -tKc o^rdev firotessoir 3r>d diicdk 七 

Redeif 七 \rctcipi - o\rdc\rp\rodcsso\r.f\rodcss0\rdc^r(o\rdc\r|ir>-fo )； 

asscv-tNotNulKv-cdcift^ctPidkufTimcf)); 
assCV*tTvuc(vctClf*t. 5 C*tCoir>-f'iVrwatioy>NumbcvO > 0); 


tKereiare no o 

Dumb Questions 


How can you just assume that the gift card has the right 
amount on it? Isn’t that an assumption? Aren’t those bad? 

J\l We’re writing our first test, and then we need to make it pass. 
So, we’re sort of assuming that the gift card has enough on it, but 
since we’re about to implement the backend code, we can make 
sure it does then. What we are setting ourselves up for is some 
refactoring. Once we get this test passing we’ll obviously need to add 
a test for a gift card that doesn’t have enough money on it. When we 
do that, we’ll certainly have to revisit the code we wrote to get this 
test going and rework it to support different gift cards and different 
values. But, this is going to take some thought. Read on... 


There are a bunch of values in that test that aren’t 
constants—should I care? 

Yes, you should. To keep the code sample short we didn’t 
pull those values into constants, but you should treat your test 
code just like production code you write and apply the same style 
and discipline. Remember, this isn’t throwaway code; it lives in the 
repository with the rest of your system, and you rely on it to let you 
know if things aren’t working right. Treat it with respect. 
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test-driven development 


Simplicity means avoiding dependencies 

Let’s add a processOrder () method to OrderProcessor, 
since that’s what our latest test needs to pass. The method should 
return a Receipt object, like this: 


0\rdc\rP\rodcsso\r 


+ p\rodcssO\rdc\r(o\rdc\r|^-fo : O\rdc\r|^-fov-ma*tioir\) : Rcdcift 


But here’s where things get tricky: processOrder () needs to 
connect to the Starbuzz database. Here’s the task that involves that 
piece of the system’s functionality: 


Task 千 

|w^lc»»'Crv"b PB 

^OV- 5'i-f-b Ords, d/mk 

irv-fo, dustowcv- m-fo, arvd 


Tit,e: ~order y OI/rcoffee 

with a gift card 

3 卜 Pr 5~ and click submit to get a 

____ 

Priority ： 


Estimate: 


Wait a second...what happened to the simplest 
code possible? Can’t we just simulate a database, 
and save writing the actual database code for 
when we get to the later task? 


Dependencies make your code more 
complex, but the point of TDD is to 
keep things as simple as possible. 

You’ve got to have processOrder () talk to a 
database, but the database access code is part of 
another task you haven’t dealt with yet. 

On top of that, is the simplest code possible to get 
this test to pass really to write database-access code? 

What would you do in this situation? 


O 
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simple code is testable code 


Always write testable code 

When you first start practicing TDD, you will often find yourself in situations where the 
code you want to test seems to depend on everything else in your project. This can often 
be a maintenance problem later on, but it’s a huge problem right now when it comes to 
TDD. Remember our rules? We really don’t want that “simplest thing” to be “an order 
processor with a database connection, four tables, and a full-time DBA.” 



Rule # 2 ： Implement tke 

SIMPLEST CODE POSSIBLE 

to make vour tests pass* 


o 


0 



And our problem is that the code for 
this task is all tied up with other tasks, 
and with database code, right? 


All real-world code has dependencies 

When you only have basic classes in your system, it’s 
not too hard to split things up so you can test pieces 
one thing at a time. But eventually, you’re going to 
have code that depends on something external to your 
system, like a database. 

This can show up lots of other ways too, though: your 
system might depend on a network connection to 
send or receive data, or you might need to read data 
from files that are created by another application, 
or you might need to use a sound API to generate 
annoying thumps and beeps. In all of these cases, the 
dependencies make it hard to test one thing at a time. 

But that doesn’t mean you don’t have to test. It just 
means you have to figure out a way to test things 
independent of all those dependencies. 



a Java-based 
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test-driven development 


Whew things get hard to test examine your design 


One of the first things you can do to remove dependencies is to see if you can 
remove the dependencies. Take a look at your design, and see if you really need 
everything to be as tightly coupled — or interdependent — as your current design 
calls for. In the case of Starbuzz, here’s what we’ve assumed so far: 


o 

Order 


DB 



P\ro^csso\r 


Utilities 

What we have... 

1 

- ^ 

/ 

- ^ 


The order processor has 
to fetch gift cards from the 
database, check the order, 
save it, and update the gift 
card (again in the database). 
So processOrder () is 
hardwired to connect to the 
database...and that’s what 
makes testing the method 
tricky. 



What we need... 

How can we have 
processOrder () make 
the same calls, but avoid 
database access code? We 
need a way to get data 
without requiring a 
database — it’s almost like we 
need a fake data access layer. 


0 

Database 


p\rodcssO\rdlc\r(...) 

分 f 七 tard 

l 

3 c 七与 C (…） ^ 

select ^ -fv-om... 

个 

TVis method 

•… te 似 ts 

di^tly with 

Code.. 

~j dhcdk bdld^des 
^ savcO\rdc\r (...) 、 

- - - 9 

-- ) 

*msc\rt m*to … 

savc^Cf.) 、 

-- ^ 

update am 七 … 

- ^4 

7 


\s V^av-dWiv-cd *to *to 




0\rdc\r 


Ttsi DB 

Pv-odcssov- 


Utilities 

L 

/ 





p\rodcssO\rdc\r(..- 


(…) 


bo 

v/ovks … 



savc^C(-) 





\rc*tu\nr\ d -fake 6{C 


These 

real ob\c^*ts ; 




… but heed "to be dble \jo swi*t^h 
*(Vorh a database autss laycv- -to a 
U -Pakc data w acuss layev-. 


ob\ 

\ M ： the 

ddis is 
y da-ta, 

— J do notlVmj... 3hd "thcv-c^s 

ho database 

— \ involved, 

-fakc-savc 6\C 
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switching to test code with the strategy pattern 


The strategy pattern provides for multiple 
implementations of a single interface 

We want to hide how the system gets gift cards, and vary it depending on 
whether we’re testing the code or we’re running the system in production. Flip 
to Chapter 1 of Head First Design Patterns and you’ll find there’s a ready made 
pattern to help us deal with just this problem: the strategy pattern. 




DBA^^cssov- 



+■ ： *m*t) ^i-f*tCa\rd 

+• savc^C^av-d : : void 

+■ savcO\rdcv(o\rdlc\r|^-fo : 0\rde\r| oyO | 


\A/i^ 

y 0[A ? vov«ac mtev+ade 
sv>c6^*«6at«o^ (or 

al—bW r> 一七 


i a da^asc, 






r 



Now we’ve got two different ways of hitting the database, and 
OrderProcessor doesn’t need to know which one it’s using. 
Instead, it just talks to the DBAccessor interface, which hides 
the details about which implementation is actually used. 

All we need to do now is add a way to give the OrderProcessor 
the correct DBAccessor implementation, based on whether the 
test code or the system is providing it. *^ 


\ 0\rdc\rP\rodcsso\r ' 

j- dbA^^cssov- : DBA^^cssov ; 


1 + sc*tDBA^CSSo\r(DBA^^CSSo\r) : void 
/ + p\rodcsO\rdc\r(o\rdc\r|^-fo : 0\"dcr |^-fo\rw\a*tioir\) 

: Rcdcift 


氺 |*f Y ouV " tus*bowCV- uy\suvc 
about database 

use m ^rodutW, 七 
sawe a^v-oatV^ v/ould wake 丨七 
easy *to ou 七 database 

ve^dovs a^d 


Tke strategy pattern 
encapsulates a family oi 
algoritkitis and makes 
tkem interckangeaLle. 
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test-driven development 





Getting to Green... again 

Now you’ve got a way to isolate the OrderProcessor class from the database. 
Implement the processOrder() method using the right database strategy. 


You II 






… save the 

o\rdc\r... 


•thch save the 
updated gi-Pt 
^a\rd badk out 



- 6(AsiomncvMan\e ： ■ 

- dy'mkPcsfivip-tio^ : 

一少不七 •: iirt 
一 fv*c-Pcyycd£'tovc|Vunf>bcy- : m-t 

- - --— 

+ sciCusiomcY'l^aimeUamc : 

+ sc-tPv'mkPcs^Hp-tioh^dcsfi : 

+ sc-t^i-f-tCavdNurwbcy^^Num : i^i) 

+ s ^'tP ,r C-('CV'VcdS'toV"c|Vurir>bcy"^urw : ih*t) 

+ ^e-iCusiomcY'I^SmcO ■ 

+ 3C-tPv'ur>kPcsfiyiptio^0 : 

+ 与 ••■^tC^vdNurnbev *。： iivt 

+ 3ctPvc-fcyycd£-tovc|Vur»»bcyO : m-t 


Receipt 


fidkufTimc : Date 

^t?>a\ay\tt ■ Bi3pe 匕 i^al 


+ sctCoir>-fivr»»atioif>Nur»>bcv-(if>o : ii^) 
+ sctPidkupTir»>c(dia-tc ： Date) 

+ sti6\Cda\aY\tc(\)a\ ■ BigDe^al) 

+ ^ctCo^-fiv-ma-tiom/Vumbcv-O : m-t 

+ ytPi 匕 kupTWO : Date 

3c 七与 CBabmdeO : Bi^Pcdimal 


^i-f tCav-d 


- a^tivatio^Pa-tc : Pa-tc 
- c^fiv-atio^Pa-tc : Pate 
一 ： 

"-f 3ctA^t'va-tioif>lPa-tcO : Us 

+ ^c-tE^fiv*atioif\Pa-tcO : Vsie 
+ ytBalawO : Bi3pctiw»al 
+ sc-tBala^c(Bi^Pc^iw>al) ： void 
+ c<\uals(objc^-t ： Object) : boolean 



you are here ► 


297 








































where to place your test code 



Getting to Green...again. 

Now you’ve got a way to isolate the OrderProcessor class from the 
database. Implement the processOrder() method using the right 
database strategy. 


as 

loy^ as youVc 

PBAdtcssov 
is jus*t 3 
^ladcV^oldcv. 

TV^c itsi 

d zjcv ■。一 

# 七 tav-d a*t 
{\\t cv>d- So 
siwul3"bc *bV>a 七 . 


ihis i Sh J i 

3ood ； ihis is 

th f tcsi bui 
^ ^ obviously g oi 

ihis - m 

鈿 oihcm icsl 


// existing code 

private DBAccessor dbAccessor; 

public void setDBAccessor(DBAccessor accessor) { 
dbAccessor = accessor; 

} 

public Receipt processOrder(Orderlnformation orderlnfo) 

今 i*P 七 Cdvd y 二 dbA^cssov-.jct^Cfov-dcv-l^-fo.yt^i-P'tC^v-dlNurwbcv-O); 

dbA^cssov-.savcOv-dcv-(ov-dlcv-l^-Po); 


// This is what ouv- -tcs-t is 

5t sc-tBala^c(^cy/ BijDcdimaKo ))； 

dbA^cssov-savc^C^t )； 

Receipt v-cdcipt ― new RcdciptO; 

vedei ptsc*tCo^-fi\rma-tio^Num bev*(l23 午弓 ); 
v-cdciptsc*tPi^kupTinr\c(^cv/ DatcO )； 
v-cdciptsrt^CBala^cfjdjc-tBala^cO); 

\rctu\rr\ v-cdciftj 


故 :㈣ 二 “ 


iheve^ 

Dumb 


are no o 

Questi 9 ns 


I just don’t buy it. We just wrote a bunch of code that 
know is wrong. How is this helping me? 


we 


The test we wrote is valid—we need that test to work. The code 
we wrote makes that test work so we can move on to the next one. 
That’s the principle behind TDD—just like we broke stories into tasks 


to get small pieces, we’re breaking our functionality into small code 
pieces. It didn’t take long to write the code to get the first test to pass 
and it won’t take long to refactor it to get the second one to pass, or 
the third. When you’re finished you’ll have a set of tests that makes 
sure the system does what it needs to, and you won’t have any more 
code than necessary to do it. 
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test-driven development 


Keep your test code with your tests 


All that’s left is to write up an implementation of DBAccessor for the 
processOrder () method to use, and finish the testSimpleOrder () 
test method. But the test implementation of DBAccessor is really only used 
for tests, so it belongs with your testing classes, not in your production code: 

^ ^\|| -tw»s toAt IS m ouv itsi dass, ^ 

^ ^\cM \S rn a separate 

public class TestOrderProcessing { 

// other tests 

^^\ rteves a S\m ? lc PBA^ssoyr 
W—me 山 W 七^七 

values >MC v/a 此 

专 ~) 

f ih f c iWls is o^ly used 

i 仏 dc-Pihcd ihside 

。听 tesi dass. 


public class TestAccessor implements DBAccessor { 
public GiftCard getGC(int geld) { 

GiftCard gc = new GiftCard(); 
gc.setActivationDate(new Date()); 
gc.setExpirationDate(new Date()); 
gc.setBalance(new BigDecimal(100)); 

} 

// ... the other DBAccessor methods go here... 



@Test 

public void testSimpleOrder() { 

// First create the order processor 

OrderProcessor orderProcessor = new OrderProcessor(); 
orderProcessor.setDBAccessor(new TestAccessor()); 



// Then we need to describe the order we r re about to place 
OrderInformation orderlnfo = new Orderlnformation(); 
order Info • setCustomerName ( 、 'Dan 〃）； 


)rdcr?roUssor 

use test 

■^r\oY\ 


orderlnfo • setDrinkDescription (''Bold with room 〃）； 

orderlnfo • setGiftCardNumber (12345) ; ]/\/\{\\ 七 he 

orderlnfo • setPreferredStoreNumber (123) ; da*bakasc attessor, 

y/e itsi 七 Wis 

// Hand it off to the order processor and check the receipt 七 Wrbt 叫 3 

Receipt receipt = orderProcessor. processOrder (orderlnfo) ; |- vc ^-tabasc- 
assertNotNull(receipt.getPickupTime ()); 
assertTrue(receipt.getConfirmationNumber() > 0); 

assertTrue (receipt. getGCBalance () . equals (0) ) ; ) Rcmcrwbcv, this was all about the 

simplest Code possible io v-ctuv-h the 
expected values hcv-c. 
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better code through testing 


Testing produces better code 

We’ve been working on testing, but writing tests first has done more than just 
test our system. It’s caused us to organize code better, keeping production 
code in one place, and everything else in another. We’ve also written simpler 
code — and although not everything in the system works yet, the parts that do 
are streamlined, without anything that’s not absolutely required. 

And, because of the tight coupling between our system’s business logic and 
database code, we implemented a design pattern, the strategy pattern. Not 
only does this make testing easier, it decouples our code, and even makes it 
easy to work with different types of databases. 


So testing first has gotten us a lot of things: 





Well-organized code. Production code is in one place; testing code is 
in another. Even implementations of our database access code used for 
testing are separate from production code. 


Code that always does the same thing. Lots of approaches to 
testing result in code that does one thing in testing, but another in 
production (ever seen an if (debug) statement?). TDD means 
writing production code, all the time. 



Loosely coupled code. Tightly coupled systems are brittle and 
difficult to maintain, not to mention really, really hard to test. Because 
we wanted to test our code, we ended up breaking our design into a 
loosely coupled, more flexible system. 


Ouv -test uses a t 士 r 

Cm 十 

oJf pBA^^ssov, but the 
ovdev 

sa^c todc, Waf A 



Ever heard your computer science professor or lead architect talking about 
low coupling and high cohesion? This is what they were talking about. We 
have low coupling because of our use of interfaces and the strategy pattern, 
and we’ve got high cohesion by having our database and business logic code 
concentrated into separate but well defined classes. 


the s'mjlc responsibility 

pv-ihdiplc? 



OvdevPvodessov 




se-tPBA^essov-(PBA^essov-) : void 
+ ^y*odessOvdev*foydie'r|n-(-o : Ovdev*|h-Pov*nr>a-tion) : Redeif't 


y° uV ^ 

^ you, DB , ode 




+ savc^C^av-d :糾七 Card) ：void 
+ savcOvdcv-Covdcv-lh-Po - Order I h-fov-matio^) 


A 


da^ase，So ^ 一 . 




These addcsso\rs v/o\r\ry about ^ 
database stress, ahd ohjy dd'tdb^se 
Sddcss. Tha*ts high dokesioh. 
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test-driven development 



O 


Are you kidding me? Did you look at that code we 
just wrote? We never once look at the expiration 
date on a gift card, and we always set the balance 
to 0. How can you call this better code? 


Your code may be incomplete, but 
it’s still in better shape. 

Remember the second rule of test-driven development? 



Rule #2: Implement tke 

SIMPLEST CODE POSSIBLE 

to make your tests pass* 


Even though not everything works, the code that we do have works, 
is testable, and is slim and uncluttered. However, it’s pretty clear 
that we still have lots of work left. The goal is getting everything else 
working and keeping any additional code just as high-quality as what 
you’ve got so far. 


f\\\ ^ov 

WW 御 咖巧， 

a^d V^okc7 

adds a tomtit 
test— a\^oatVv 


So once you get your basic tests, start thinking about what else you 
need to test...which will motivate the next piece of functionality to 
write code for. Sometimes it’s obvious what to test next, like adding a 
test to deal with gift card balances. Other times, the user story might 
detail additional functionality to work on. And once all that’s done, 
think about things like testing for boundary conditions, passing in 
invalid values, scalability tests, etc. 


We’ve implemented the basic success-case test for processing 
an order, but there are clearly problems with our implementation. 
Write another test that finds one of those problems, and then write 
code to get the test to pass. 
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tests = code and lots of it 


More tests always means 


lots 

more 


code 


The gift card class for Starbuzz has four attributes, 
so we’re going to need several tests to exercise those 
attributes. We could test for: 


I I A gift card with more than enough to cover the cost of the order 

I I A gift card without enough to cover the cost of the order 

I I An invalid gift card number 
I I A gift card with exactly the right amount 

I I A gift card that hasn’t been activated 

I I A gift card that’s expired 



\ y \ tasc, wc 

a card 
ob\c^t wi 七 V) a sli# 七 ly 

ditfev* 伙七 set 
values, so y/c 七 es 七 

ed^V) vav-ia*bior\ m ou\r 
oY&tr pv-otess'm^ dass. 


And that’s just for the gift cards. You’ll need tests for variations on the 
Order Informat ion class, too...and we still haven’t tested for the bigger 
failure cases, like what happens if the database fails to save an order. 



These are really important things to test, but 
not only are we going to have to write tests for 
these cases, were going to have to write up a 
bunch of strategies too... 


Automated test-driven development 
means a LOT of test code. 

The more functionality you have, the more tests 
you’ll need. And more tests means more code... 
lots and lots of code. But all that code also means 
a lot more stability. You’ll know your system is 
working, at every step of the way. 

And sometimes, you may not need quite as much 
code as you first thought... 
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test-driven development 


Strategy patterns, loose 
couplings, object stand ins... 

Suppose we used the strategy pattern again for all the different 
variations on the types of gift card a database could return, like this: 


s 5 似 e 3 y 




+ 


3 亡七今 C(3 匕 Id : int) ： ^i-ftCa 
savc^CCdav-d : ^i-PtCav-d) 


vd 
v-d) : void 


A 


ttcv-c s {\\t v-cal 

autssor. 


广 




To avoid all these extra classes, you could have one 


cvvor v-c^ 


TestDBAccessor implementation that returned different 
cards based on the ID you gave it, but that’s screwing up loose 
coupling. TestDBAccessor would have to be in sync with 
your test code to make sure they agree on what each ID means. 


But each test gift card accessor 
shares a lot of code, and thafs 
bad, too...so what do we do? 



O 
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mock objects 


Wc need lots of different but similar, objects 

The problem right now is that we have a sequence like this: 


0\rdc\r 

Pv-odcssov- 


Test PB 

Utilities 


八 


p\rodcssO\rdc\r(...) 


/ 


(\ci6C (■- 



s 


ave 今 C (… 


— j VC*tu\r^ a spcdi-f i£. ^_ ) 

u#i4-k •二 iw 


rt 的、 讪⑽ ^ jyroWcm »s ： U ca 

Wt 切 ? d 

a tesU' 3SS ^ 


••) 


6\C dc\r*ta*m 
values 


、 J do ••• 


-fakc-savc the 6\C 

Th ' s is ^ ^ bu-t si^c -the 
p^csso^ has -to can 

thcsc we heed ah 

muesso^. 


7cs*t^oodPBA^^css 


ov 


+ 3c*t^C(jd|d : m*t) ^i*P*tCav-d 
+ savc^C^avd : ^i-ftCav-d) : void 


Tcs-tlnsu-P-fidic^-tDBA^CSSov 


+ 


^ti6\CUcld ' m*t) ： ^i-P*tCa 
savc^C^av-d : ^i-PtCav-d) 


vd 
v-d) : void 


TcstlnvalidDBA^cssov- 


+ ^ti6\CUtld ' in*t) ： ^i-P*tCav-d 
+ savc^C^avd : ^i-ftCav-d) : void 


What if we generated objects? 

Instead of writing all these DBAccessor implementations, 
what if we had a tool — or a framework — that we could tell 
to create a new object, conforming to a certain interface (like 
DBAccessor), and that would behave in a certain way, like 
returning a gift card with a zero balance provided a certain 
input was passed in? 

Youv itsi 6odc use tw»s 
like aq o*tV^ … rb 

“ ? 1 加山 pfcA 如 s? 

|ooks>stl\kcavcaUbss^at 

Wd — 七 c Youvsclf 


Youv 6odc -tells -tv^c 

^vawcv/o\rk »*t needs. 

I want a DBAccessor implementation that 
returns a GiftCard with a zero balance, please. 
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Here’s an object... if you 
call getGC() with a value 
of “12345，” it will do just 
what you want. 



^losi bhguays have a ; 

-P\ramcwo\rk jus-t like "this—just 

google 、。乙 k objects. w 


Mock Object 
Framework 










































test-driven development 


A mock object stands m for real objects 

There’s really no need for three different accessors, all of which create a new Gif tCard 
object and populate it with different data. That’s a lot of extra code to instantiate a 
Gif tCard and call some setter methods. 


Since we have an interface that describes what each of these implementations should look 
like, we can take advantage of a mock object framework to do the heavy lifting. Instead 
of implementing all of the classes ourselves, we can give the framework the interface we 
want implemented and then tell it what we expect to happen. 

f ⑽一 士:工 工 




PBA^cssov- 


+ ' mt) ^i-PiCav-d 

+ savc^C^av-d : ^i-ftCav-d) : void 








ouir \rc^l 
觸 L 。叱 


广 




The mock framework will handle creating implementations of the interface and keeping track 
of what methods we say should be called, what they should return when they are called, what 
shouldn’t be called, etc. The mock framework’s implementation of our interface will track all of 
this and throw an error if something doesn’t go according to the plan we gave it. 

本 IVlcVc jomg *bo use B-SsyModk -fv-amev/ovk hcv-c bu*t S 你。匕 k object -fvarwcv/ovk c>0s*ts 
-fov- r»\os*t dll v/ovk sirwilav-ly. 
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using a mock object framework 


Mock objects are working object stawd-iws 


Let’s look at a mock object framework in action. Below is a test that uses the EasyMock 
framework, a mock object framework for Java. A good mock object framework allows you to 
simulate an object’s behavior, without writing code for that object. 


import org•easymock•*; 


-Pv-amcwov-k 
you u% youll heed -to 
i^pov-t the \right classes. 



// This test will test placing an order with a valid gift card 
// with exactly the right amount of money on it. 

@Test 

public void testSimpleOrder() { 

// Set everything up and get ready 


T his is all 

二: it， “ 


OrderInformation 


new Orderlnformation() 


orderlnfo . setCustomerName ( 、 'Dan 〃）； 


This is 
all w 灼。 vmal” 
dodc- 



TW»s sc-b ^ tcs-b vaWcs 

滅:心 . 


Y\o m 



orderlnf o . setDrinkDescription (''Bold with room ’’）； 
orderlnf◦.setGiftCardNumber(12345); 
orderlnfo.setPreferredStoreNumber(123); 

Date activationDate = new Date(); // Valid starting today 
Date exiprationDate = new Date(activationDate.getTime() + 3600); 
BigDecimal gcValue = new BigDecimal (''2.75^) ; // Exactly enough 
GiftCard startGC = - - - 






new GiftCard(activationDate, expirationDate, gcValue); 
BigDecimal gcEndValue = new BigDecimal (、'◦") ; // Nothing left 
GiftCard endGC = 


七 

dav~d- This has 

new GiftCard (activationDate A expirationDate, gcEndValue) ; what should be 

VC*tuV^cd -Pv-om 
ov-dev- 

// Here's where the mock object creation happens 

EasyMock.createMock(DBAccessor.class); 


vVc Y/ay>*t object 
•，— emevrU 七 Wis 




...so wc ic\\ ou\r -f\ramcv/o\rk *bo B modk 

object implements *thc vijh-t 
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test-driven development 


Oy\Ct you dv-catc a nr»odk it’s ih \ttoY& 


obw 




rwode. That ^cby\s you tell i 七 what io c^pcd-t and 
what h> do so y/hcir> you pu 七 i*t m vcplay mode, 
ahd youir tests use ii, you ; vc sci up e 乂 adj y 山七 
the modk object should do. 


R cw cwWM 0VA 

ViVltT'/OUV 

Mass... 

i\\t 


// Tell our test framework what to call, and what to expect 
EasyMock.expect(mockAccessor.getGC(12345)).andReturn(startGC); 



object >wc scaled ovcv Wc. 




I^VVh gct^CO is caWtd that 

\rclu\rh -the sia\ri6iC object., -this 
si^ula-tcs gc-ttmg a ^av-d -Pv-o^ the 
database, wc'vc supplied the e 成七 
values wc waht -Poir -this test sdCh^io? 

// Simulate processing an order 一 T ^- lS aoesh t do \i tells t^c motk 

mockAccessor . saveOrder (orderInfo) ; ob\c^*t you should Have savcOv-dc'rO called, 

ovd^l^o as f aramcW. Oi^st, 

3 o^ 扣 d »t should tWow 孙 

// Then the processor should call saveGC(...) with an empty GC 


mockAccessor.saveGC(endGC); 



^ ^- ^ with these values, the icsi shlld ^ 


// And nothing else should get called on our mock. 

EasyMock. replay (mockAccessor); 心 "•， 丨 

^afL2% K :!:以 

一 y these —, so ge-tLdy^ 

tw»s »s V»kc 

OrderProcessor processor = new OrderProcessor(); 



// Create an OrderProcessor... 


processor.setDBAccessor(mockAccessor); - - 

Receipt rpt = processor.processOrder(orderlnfo); 


0 W6t ； »t ，s 

-to be used ⑽ 从 


// Validate receipt... 



A»>d V>cv-cs 々代从 $ 巧 孓脉⑽饮 

峰❹ £：: 


5 fp 

SsU ⑽一斗融』 


[ h,s ^9^ ^ like a good bit wovk 

N'T ： / WC VC savcd 。吡如 .Add ih 
all 七 ^ othev vairiatiohs o-P t«ti h a 

yh u >rd th—, ahd youll save 
o 士 classes..，ahd 3 big deal. 
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why mock objects? 



These mock objects don’t seem to be doing anything I 
couldn’t do myself. What are they buying me again? 


What about arguments...you say they’re compared with 
Java’s equals( ) method? 


Mock objects give you a way to create custom implementations 
of interfaces without needing to actually write the code. Just look 
at page 303. We needed three different variations of gift cards (if 
you count the testlnvalidGiftCard one). Two of them had different 
behavior, not just different values. Without the mock objects we’d 
have to implement that code ourselves. You could do it, but why? 

Why didn’t we use mock objects for the gift cards 
themselves? 

Well, two reasons. First, we’d have to introduce an interface 
for the gift cards. Since we don’t have any behavioral variations it 
really doesn’t make a lot of sense to put an interface here. Second, 
all we're really changing are the values it returns since it’s pretty 
much a simple data object anyway. We can get that same result by 
just instantiating a couple different gift cards at the beginning of our 
test and set them to have the values we want. Mock objects (and the 
required interface) would be overkill here. 

Speaking of interfaces, doesn’t this mean I’ll need an 
interface at any point I’d want a mock object in my tests? 


Right—EasyMock tests the arguments the mock object gets 
during execution against the ones you said it should get by using 
the equals () method. This means you need to provide an 
equals () method on classes you use for arguments to methods. 
There are other comparison operators to help you deal with things 
like arrays where the reference value is actually compared. Check 
out the EasyMock docs (www.easymock.org/Documentation) for 
more details. 

So we changed our design a pretty good bit to get all this 
testing stuff going. The design feels., upside-down. We’re telling 
the OrderProcessor how to talk to the database now... 

Yes, we are. This pattern is called dependency injection, and 
it shows up in a lot of frameworks. Specifically the Spring Framework 
is built on the concepts of dependency injection and inversion of 
control. In general, dependency injection really supports testing— 
particularly in cases where you need to hide something ugly like a 
database or the network. It’s all about dependency management and 
limiting how much of the system you need to be concerned about for 
any given test. 


Yes—and truthfully sometimes you end up putting interfaces 
in places that you really don’t ever intend on having more than one 
implementation. It's not ideal, but as long as you’re aware that you’re 
adding the interface strictly for testing it’s not usually a big deal. 
Generally the value you get from being able to unit-test effectively 
with less test code makes it worth the trade-off. 

What’s that replay(...) method all about? 

That’s how you tell the mock object that you’re done telling it 
what’s about to happen. Once you call replay on the mock object it 
will verify any method calls it gets after that. If it gets calls it wasn’t 
expecting, in a different order, or with different arguments, it will throw 
an exception (and thereby fail your test). 


C^: So do you need dependency 
or mock objects? 


injection to do good testing 


No. You could do a lot of what we did with the DBAccessor 
by using a factory pattern that can create different kinds of 
DBAccessors. However, some people feel that dependency 
injection just feels cleaner. It does have an impact on your design, 
and it does often mean adding an interface where you might not have 
put one before, but those typically aren’t the parts of your design 
that cause problems; it's usually that part of the code that no one 
bothered to look at because time was getting tight and the project 
had to ship. 
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test-driven development 


ftood software is testable... 

There are lots of things to think about when designing software: reusability, clean APIs, 
design patterns, etc. Equally important is to think about your code’s testability. We’ve 
talked about a few measures of testability like well-factored code and code coverage. 
However, don’t forget that just because you have JUnit running on every commit that your 
code isn’t guaranteed to be good. 

There are a few testing bad habits you need to watch out for: 



A whole - lotta - nuthiw' 

If you’re new to test driven development it’s very easy to write a whole lot of test code 
but not really test anything. For example, you could write a test that places a Starbuzz 
order but never checks the gift card value or receipt after the order is placed “Didn’t 
throw an exception? Good to go.” That’s a lot like saying “it compiles — ship it.’’ 


It's stHI me... 



In an overeager attempt to validate data it’s easy to go crazy testing fake data you fed 
into the system initially and miss the actual code you need to test. For example, suppose 
you write a test that checks that the gift card value and expiration date are correct when 
you call getGC () ... on our TestDBAccessor. This is a simplistic example but if 
you’re traversing a few layers of code with your test, it’s not too hard to forget that you 
put the value you’re about to test in there in the first place. 


Ghosts from the past 



You need to be extremely careful that your system is in a known state every time your 
automated tests kick off. If you don’t have an established pattern for how to write your 
tests (like rolling back database transactions at the end of each test) it’s very easy to leave 
scraps of test results laying around in the system. Even worse is writing other tests that 
rely on these scraps being there. For example, imagine if our end-to-end testing placed 
an order, and then a subsequent test used the same gift card to test the “insufficient 
funds” test. What happens the second time this pair of tests execute? What if someone 
just reruns the second test? Each test should execute from a known, restorable state. 


There are a lot of ways to write bad tests — these are just a few of them. Pick 
your search engine of choice and do a search for “TDD antipatterns，’ to find 
a whole lot more. Don’t let the possibility of bad tests scare you off, though — 
just like everything else, the more tests you write the better you’ll get at it! 
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all green, you’re done 


Ifs wot easy bein' greew. 


You did it — through the help of the strategy pattern, dependency injection (see the previous ]s(o 
Dumb Questions), and mock objects, you have a really powerful, but not too bulky, suite of unit 
tests. You now have piles of tests that make sure your system does what it’s supposed to be doing 
at all times. So to keep your system in line: 

o Always write a test before you write the real production code. 

❺ Make sure your test fails, and then implement the simplest thing that will 
make that test pass. 

❺ Each test should really only test one thing; that might mean more than one 
assertion, but one real concept. 

o Once your’re back to green (your test passes) you can refactor some 
surrounding code if you saw something you didn’t like. No new 
functionality~just cleanup and reorganization. 

o Start over with the next test. When you’re out of tests to write, you’re done! 


Whew all of your tests pass, you're done 

Before we never really had a way of knowing when we were finished. You wrote a bunch of 
code, probably ran it a few times to make sure it seemed to be working, and then moved on. 
Unless someone said something bad happened, most developers won’t look back. With test- 
driven development we know exactly when we’re done — and exactly what works. 




?)oV) af 


File Edit Window Help Bliss 


hfsd> java -cp junit.jar;. org.junit.runner.JUnitCore 

headfirst.sd.chapter8.TestOrderProcessor 

JUnit version 4.4 


Time : 0.321 
OK (86 test) 

hfsd> 


^ ih 
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test-driven development 




TDDcross 


The crossword tests are below; fill in 
the answers to make each one pass. 



Across 

2. You ain't gonna need it. 

3. Red, Green,. 

5. TDD. 

6. Mock objects realize. 

8. Bad approaches to TDD are called. 

10. TDD means writing tests. 

12. To do effective TDD you need to have low. 

13. To help reduce dependencies to real classes you can 

use . 


Down 

I. Fine grained tests. 

4. When you should test. 

7. Write the.code that will get the test to pass. 

9.testing is essential to TDD. 

10. Your tests should.at first. 

II. To help reduce test code you can use.objects. 


Answers on pa^e 315. 


► 
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test, red, code, green 


A day in the life of a 
test-driven developer 


Once you have your tests passing, you know you built what you 
set out to. You’re done. Check the code in, knowing that your 
version control tool will ping your Cl tool, which will diligently 
check out your new code, build it, and run your tests. All night. 
All the next day. Even when Bob checks in some code that 
breaks yours."# 

Then the automated mail starts.... 


(l) Start with the task you’re 
going to work on. 


Title: 


border your coffee 
wifhagift wr d 

Priority: 


20 


Task / 

oy-der 
ta^rd 
i h 4. 


5 


Write code to get your test to pass, refactor, ^ 

V—^ orlrl onnthar tact onrl not it nocc Repeat 々 —*to 乂七 "^35^ 


add another test, and get it to pass, 
until you run out of tests to add. 




blic void 


public void 

testGetOrderHistory3 

{ 

// Test '''' username 


A. 


\ 



\y 


i\^ei sta^ ?assmy- 


suve 


d^d wove 


J^el 


■ 


public void 
testGetOrderHistory3 


// Test 


Real i^plc^ch-ta-t' 

to&t 




ioh 


bu*t m 此 v/i*th TW, Bob will know m! 
because -the *tcs*ts v/ill -fail By\A he v/ill know 
wha 七 Code he bvokc. 
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test-driven development 


(§) Work up the first test for the very 
first piece of functionality you need 
to implement. You’re now Red. 


This icsi is 


④ Refactor any code you want cleaned up, 
then write the next test...Red again. 


( 5 ) Write the simplest implementation 
code you can to get the test to pass. 
YoiTro now Green. 



public void GetOrderHistory3 



new 


{ ^ 

OrderHistory 
OrderHistory(); 

System.out.println (''Hi 
mom!"); 

} 


public void 

testGetOrderHistory3 

{ ~~ 


// Test username 



publii^goid GetOrderHistor 


y3() 1 


OrderHistory = new 
ORd^rHistory(); 


. out. println (''Hi 


mom!"); 


；^ should still be 


passih 9 -but the hCW OhC Will 4il 
: jil you implcmch-t hCw SU* 
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you/* so 疗 ware development toolbox 



Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter, 


you learned about several techniques to keep 


you on track. For a complete list of tools in the 


book, see Appendix ii. 


Development 


coAt ^ -akc 

i^ost tests ?ass 

r tests should ^\\ W 七 _ 如 

*tv>c7 ?ass YOU rt^cb>>r 

Use motk ^ — 十 ^\ai\o^s 

or, objeds tv>at YOU r^ttA W 


扣 C SOnr>C 

the key 
ic^hhi^ucs you 
m -this 

匕 —tar … 


av\d sowc 




yr\U\^ bcWmd 
从 osc tc6W»°\VACS. 


Developrhe^ PH^ipU^ 


TDD Ws you -to 4dus oh 

Automated iesis make ‘; 

you II khow immediately i-p you've bvokeh 
sonr»c*thihg 

今 。 od CoAt dovevage is ㈣ 乩 move 
achievable ih a TDD ay^oac^ 


BULLET POINTS 

■ TDD means you'll be 
refactoring code a lot. 
Break something pretty bad? 
Just use your version control 
tool to roll back to where you 
were earlier and try again. 

■ Sometimes testing will 
influence your design— be 
aware of the trade-offs and 
deliberately make the choice 
as to whether it’s worth the 
increased testability. 

■ Use the strategy pattern 
with dependency injection 
to help decouple classes. 

■ Keep your tests in a parallel 
structure to your source 
code, such as in a tests/ 
directory. Most build and 
automated testing tools play 
nicely with that setup. 

■ Try to keep your build and 
test execution time down 

so running the full suite of 
tests doesn’t hold back your 
development speed. 
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test-driven development 



TDDcross Solution 

The crossword tests are below—fill in 
the answers to make each one pass. 
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9 ending an 





It’s all coming together. 


w 


Wait until you try this. 

Ive been working on it all month, 
and ifs exactly how you like it. 


You’re almost finished! The team’s been working hard, and things are 
wrapping up. Your tasks and user stories are complete, but what’s the best way 
to spend that extra day you ended up with? Where does user testing fit in? Can 
you squeeze in one more round of refactoring and redesign? And there sure 
are a lot of lingering bugs. ..when do those get fixed? It’s all part of the end of an 
iteration... so let’s get started on getting finished. 


this is a new chapter 
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results from an iteration 


Your iteration is just about complete... 

You’ve made it! You’ve successfully put your process in place: the stories 
have piled up in the Completed section of your board, and everyone’s 
ready for a little breather. Before people head out for the weekend, 
though, let’s do a quick status check: 


Whctt WeVe got 


Customer-driven functionality 



W\{}\ 七 d 
dv*ivc^ 
development 

a 灼 d 七 ed 

youv 
CoAt y/ov*ks... 
ar>di you II always 
kr>ow i-P i*t 




Compiling code 

Monitored builds 
Continuously tested code 
Solid test coverage 
Reliable progress tracking ^ 
Pacing that adapts to the team 


That’s an impressive list — but don’t turn the 
lights out in the office just yet. Suppose all your 
hard work has resulted in a day or two to spare 
at the end of your iteration. What else could you 
do if you had more time? 

Skeptical you Could have -time Ic-ft? 
A good vdo^i-ty takubtioh, s-bymg 
on -task, cs-tima'tcs will 

you thc\rc -fasten th 如 you thmk 




u ki^ow i-f someone *tvics *bo dhe 匕 k m 
Code 七 wem ’ 七 build—a^d because o( 
^o^tmuous you k 灼 ov/ you\r 

Code is always buildable- 
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ending an iteration 


..but there's lots left you could do 

There are always more things you can do on a project. One benefit of iterative 
development is that you get a chance to step back and think about what you’ve 
just built every month or so. But lots of the time, you’ll end up wishing you’d 
done a few things differently. Or, maybe you’ll think of a few things you wish 
you could still do... 


You^vc wov-ked hard puttmj this 
pv-o^css -toythev-, bu 七 the whole 

WWwe (faA kve 


da 灼 you improve youv* p\ro^csscs oy\ 
the i*bcv-a*bioir\? 


Evcv-yohc dodumchtcd theiv- 
to At } \right? Uo -typos, 
ruisspdliihs, o\r ihdornplctc ? 


⑼ XT 3 ‘ a 


rhoire 

•Oh, 


Process improvements 
System testing 


/ , I ；! + cs -b, but 'asC'ts 

wet AM — aUa T ^ md 

twy best testes 


Refactoring of code using lessons you’ve learned 


I I Code cleanup and documentation updates 



dir^r cs n dcs ' 3h 

does, i ^l, y show M ^ 

工产， /W^ybe you 3 

ft V C 1 a Ac 

巧 e m the 飢州 心地 


t 


More design patterns? 

Development environment updates 

R&D on a new technology you’re 
considering 

Personal development time to let people 
explore new tools or read 


attev ^ OVAV )\\ 


sYicctcv- po 


aM 減 k 七 W Oo 7 祕 ? 呼出 . 


"ThcvVs dlv/dys some Y\t^J 'bool OU"t 
"thcv-c 七 ha 七 v/ill Vcvolu-tioir»iz^ w 
youv- build c^viv-o^mc^'t—ov- maybe 
you jus*t v\ccd b> v-cov-ja^izjc 
dcpc^dc^ics. Ei*thc\r way, v/hen 
do you update youv- 





Which of these things would you feel like you have to do? Which ones do 
you think you should do? Are there things that can be put off indefinitely? 
Are there other things you’d like to do that are not on this list? 
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daily standup meetings 


Standup Meeting 




refactor it. A way better design came to me last night at the gym! 


Mark: No way. Have you seen some of the documentation Bob put in 
there? I mean, it’s English, I guess, but it needs some work. So no time for 
more code changes; we’ve got to work on the documentation. 


Bob: Hey — back off. It says what the code does, right? Besides, we really 
need to test more. Everybody’s tests pass, but I’m just not convinced the 
user isn’t going to get confused navigating through some of the site’s 
pages. And I’d like to run the app for at least a day straight, make sure 
we’re not chewing up resources somewhere. 


Laura: But we’re going to have to add more complex ordering in the 
next iteration; the current framework just isn’t going to hold up. I need to 
get in there and sort this out before we build more on top of it. 


Mark: Are you listening? The documentation’s awful] that’s got to be 
the priority with the time we’ve got left. 

Bob: We need to focus on the project — how did our burn-down rate look 
this iteration? Where did we spend our time? 


- Stan 耐 Meeting Tifs for pros — 

• Keep them to 10 people or less. 

• Literally stand up to help keep them short — 
ideally 15 minutes or less, 30 if you absolutely 
have to, but then kick everyone out. 

• Meet at the same time, same place, every 
day, ideally in the morning, and make them 
mandatory. 

• Only people with direct, immediate impact on 
the progress of the iteration should participate; 
this is typically the development team and 
possibly a tester, marketing, etc. 


• Everyone must feel comfortable talking honestly: 
standups are about communication and 
bringing the whole team to bear on immediate 
problems. 

• Always report on what you did yesterday, what you’re 
going to do today, and what is holding you up. Focus 
on the outstanding tasks! 

• Take things offline to solve bigger issues — 
remember, 15 minutes. 

• Standups should build the sense of team: 
be supportive, solve hard issues offline, and 
communicate! 
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ending an iteration 



E%eftclSe 


Do you think the tasks you’d do at the end of an iteration should be changed based on how the 
iteration progressed? Below are three different burn-down graphs. Can you figure out how the 
iteration went in each case? Describe what you think happened in the provided blanks. 


BuVh Poy/h 




BuVh VoY/Y\ 




Buv*r\ J)oy/y\ 
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burn-down analysis 



Before we go on let’s take a look at some burn rates. Your job was to take a look at each graph 
and figure out what probably went on during that iteration. 


BuVh Poy/h 





I 的 -this jv-aph, v/ovk vcmaming kcp*t as 

the .Tb?. 

some tWmjs m ^ci\r usc\r s^oy-ics ； r^aybe jots of 

yi”pl 咖 c4. .i? s b-y-cr»\c^lpcV> X^A K J)rcat 

•foy* -thosc-or bad estima-tes that ^o-jt u^oycy-cdi 
y/hch. uscy* stories v/cy-c b)rokc^ dov/^ *mio tasks. 

Notc . 七卜 steep.drop.at.the c^dl—odds arc 

.icarif) had .ip pui o\r. d\rop. ?ioVj?. s ..... 

^Jio^cihcio. as. deddli^es siavied .^jrccpi^g. up ； . 


Bu\rh Voy/y\ 





This is a pc\r-fc4*t ^y-apli—wha*t cyc\ry -team y/a^*b ； 
The *tcam probably had a jood ided wha*t 
y/c\rc m*to ； *thci.\r estimates y/c\rc 

dose, at both . 七 ho s .d ?ioy-y and -tcisk Icycj,. 

■they , moved i-WoujJK .i^sks a^d. s^oyics ai a. ^i^c.. 
pxcdi^'tcibjc .pa.^c ： .Remembev；,. a. good, iicy-oiiio^.... 

,dp 以 d Wye. jo^s. of, : t—c. ib?. .c^.drr.ii.c.^d s .... 
y-igbi ii!?. 兒 bjyiWfid ,*tp ： . 


Buv*r\ J)oy/y\ 




I 灼 -this jv-aph, *thc v/o\rk jus 七 keeps dv-i-ftmj *to 

*thc \ri^h£ the ideal bur^-doy/^ y-a*tc ; Chafes av-c 
ihl s . A s .. 和 . cstima-tc py-oblcm. 奸 ?!^.?. 1 ?'/. y;^). 

spikes m the woy-k so its ^o*t likely 
y/cy-c -(^o many the -team did^^-t ^.9Tj. 

bu-t -they. jus*t severely u>}dcy-cs-tjmaj：ccl how lo^g 
tWmjs would -take..jy # o*tidc -they. 七 ii..ip..... 
zLcy-p .K^.-.-.Tbc . sKp^W .b«iyc. d 1 r. 9 p.pcd.. 

s^pyj(!s -to ^^4. ibf. p*?. ii»y\ 諄 ••. 
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ending an iteration 


thereiave no ^ 

Dumb Questi9ns 


How do you know the first graph 
is things the team missed? Couldn’t it 
be things they didn’t expect, like extra 
demos or presentations? 

Absolutely. The burn-down graph isn’t 
enough to go on to determine where all 
those extra work items came from. You need 
to look at the completed tasks and figure out 
whether the extra work came from outside 
forces that you couldn’t control or if they 
were a result of not really understanding 
what the team was getting into. Either way, 
it’s important to make progress in addressing 
the extra work before the next iteration. If the 
work came from outside sources, can you do 
something to limit that from happening again, 
or at least incorporate it into your work for 
the estimate? For example, if the marketing 
team keeps asking you for demos, can you 
pick one day a week where they could get 
a demo if needed? You can block that time 
off and count it toward the total work left. 

You can use the same approach if things 
like recruiting or interviewing candidate 
team members is taking time away from 
development. Remember—your job is to do 
what the customer wants. However, it’s 
also your responsibility to know where your 
time is going and prioritize appropriately. 

If the extra work came from not 
understanding what you were getting into, do 
you have a better sense now, after working 
on the project for another iteration? Would 
spending more time during task breakdowns 
help the team get a better sense of what 
has to be done? Maybe some more up-front 
design, or possibly quick-and-dirty code 
(called spike implementations) to help shake 
out the details? 

So spending more time doing 
up-front design usually helps create 
better burn-down rates, right? 

Maybe...but not necessarily. First, 
remember that by the time you start doing 


design, you’re already into your iteration. 
Ideally you’d find those issues earlier. 

It’s also important to think about when is the 
right time to do the design for an iteration. 
Some teams do most of the detailed design 
work at the beginning of the iteration to get 
a good grasp of everything that needs to be 
done. That's not necessarily a bad approach, 
but keep an eye on how efficient you are 
with your designs. If you had driven a couple 
stories to completion before you worked 
up designs for some of the remaining ones, 
would you have known more about the rest 
of the iteration? Would the design work have 
gone faster, or would you realize things 
you’d need to go back and fix in the first few 
stories? It’s a trade off between how much 
up-front design you do before you start 
coding. 

Having said all of that, sometimes doing 
some rough whiteboard design sketches 
and spending a little extra time estimating 
poorly understood stories can help a lot with 
identifying any problem issues. 

For that third graph, couldn’t the 
velocity be a big part of the problem? 

That’s a possibility, for sure. It could 
either be that the team’s estimates were 
wrong and things just took a lot longer than 
they thought the would, or their estimates 
were reasonable but they just couldn't 
implement as fast as they thought. At the 
end of the day it doesn’t make too much 
difference. As long as a team is consistent 
with their estimates, then velocity can 
be tweaked to compensate for over- or 
underestimating. What you cfon’f want to do 
is keep shifting your estimates around. Keep 
trying to estimate for that ideal workday 
for your average developer —that person 
was locked in a room with a computer and 
a case of Jolt, how long would it take? Then, 
use velocity to adjust for the reality of your 
work environment and mixed skill level on 
your team. 


Q/ So should the team with the third 
graph just add time to the end of their 
iteration to get the extra work done? 

In general that’s not a great idea. 
Typically, when the burn-down graph looks 
like that, people are already working hard 
and feeling stressed. Remember one of 
the benefits of that graph on the board is 
communication—everyone sees it at each 
standup, and they know things are running 
behind. Adding a day or two is usually OK in 
a crisis, but not something you want to do on 
a regular basis. Adding a week or two... well, 
unless it's your last iteration, that’s probably 
not a good idea. It’s generally better to 
punt on a user story or two and move them 
to the next iteration. Clean up the stories 
you finished, get the tests passing, and let 
everyone take a breather. You can adjust 
your velocity and get a handle on what went 
wrong before you start the next iteration, and 
go into it with a refreshed team and a more 
realistic pace. 

We have one guy who just 
constantly underestimates how long 
something is going to take and wrecks 
our burn-down. How do we handle that? 

First, try to handle the bad estimates 
during estimation, and remember, you 
should be estimating as a team. Try 
reminding the person that they aren’t 
estimating for themselves, but for the 
average person on your team. If that still 
doesn’t work, try keeping track of the date 
a task gets moved to In Progress, and then 
the date it gets moved to Done. At the end 
of your iteration, use that information to 
calibrate your estimations. Remember, this 
isn’t about making anyone feel bad because 
they took longer than originally expected; 
it’s to calibrate your estimates from the 
beginning. 
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system testing 


System testing MUST be done... 

Your system has to work, and that means using the system. So 
you’ve got to either have a dedicated end-to-end system testing 
period, or you actually let the real users work on the system (even if 
it’s on a beta release). No matter which route you go, you’ve got to 
test the system in a situation that’s as close to real-world as you can 
manage. That’s called system testing, and it’s all about reality, 
and the system as a whole, rather than all its individual parts. 



Weve written a ton of tests to cover all 
kinds of conditions. Aren’t we already 
doing system testing? 


So far, we’ve been unit testing. Our tests focus on small pieces 
of code, one at a time, and deliberately try to isolate components 
from each other to minimize dependencies. This works great 
for automated test suites, but can potentially miss bugs that only 
show up when components interact, or when real, live users start 
banging on your system. 

And that’s where system testing comes in: hooking everything 
together and treating the system like a black box. You’re not 
thinking about how to avoid garbage collection, or creating a new 
instance of your RouteFinder object. Instead, you’re focusing 
on the functionality the customer asked for... and making sure 
your system handles that functionality. 


(System testing exercises tke 

FUMCTIQMLITY ol tke 

system Irom front to Lack in 
real-world, tlack-tox scenarios. 
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but WHO does system testing? 


You should try your best to have a different set of people doing your 
system testing. It’s not that developers aren’t really bright people; it’s just 
that dedicated testers bring a testing mentality to your project. 


Peveloper testing T es f e r testing 



Developers come preloaded with lots of 
knowledge about the system and how things 
work underneath. No matter how hard they 
try, it’s really tough for developers to put 
themselves in the shoes of end users 
when they use the system. Once you’ve seen 
the guts, you just can’t go back. 


Testers can often bring a fresh perspective 
to the project. They approach the system 
with a fundamentally different view. They’re 
trying to find bugs. They don’t care how slick 
your multithreaded, templated, massively 
parallel configuration file parser is. They 
just want the system to work. 



Dumb Quest! 


9ns 


So developers can’t be testers? We can’t afford a separate 
test team! 

Ideally, you’d have developers doing your unit testing with an 
automated approach, and a different group of people doing the full, 
black-box system testing. But, if that’s not doable, then at a 


minimum, don’t let a developer black-box-test their own code. They 
just know too much about the code, and it’s way too easy to steer 
clear of that sketchy part of the code that just might fail. 


Never system-test your 
You know it too well to 


own code! 
te unLiasecL 
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incorporating system testing 


System testing depends oh a 
complete system to test 

If you’re velocity is pretty accurate and your estimates are on, you should 
have a reasonably full iteration. It also means you don’t have a stack 
of empty days for system testing...and on top of that, you won’t have a 
system to test until the end of your iteration. 



At a minimum, the system needs to get out for system testing at the end 
of each iteration. The system won’t have all of its functionality in the earl) 
iterations, but there should always be some completed stories that can be 
tested for functionality. 


如 should be 七 cs 七 ， all 
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Dumb Questi9ns 


Can’t we start system testing earlier? 

Technically, you can start system testing earlier in an iteration, 
but you really have to think about whether that makes much sense. 
Within an iteration, developers often need to refactor, break, fix, 
clean up, and implement code. Having to deliver a build to another 
group in the middle of an iteration is extremely distracting and 
likely to including half-baked features. You also want to try to avoid 
doing bug fix builds in the middle of an iteration—an iteration is a 
fixed amount of time the team has to make changes to the system. 


They need to have the freedom to get work done without worrying 
about what code goes in which build during the iteration. Builds get 
distributed at the end of an iteration—protect your team in between! 

So what about the people doing testing? Where do they 

fit in? 

It's definitely best to have a separate group doing system 
testing, but as for what they should do while your main team is 
writing code, that’s a good question. And even if you have other 
developers do system testing, the question still applies... 
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ending an iteration 


ftood system testing requires 
TWO iteration cycles 


Iterations help your team stay focused, deal with just a manageable 
amount of user stories, and keep you from getting too far ahead 
without built-in checkpoints with your customer. 

But you need all the same things for good system testing. So what if 
you had two cycles of iterations going on? 
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issues with test iterations 


More itcratiows means more problems 

System testing works best with two separate teams, working two 
separate iteration cycles. But with more iterations comes more 
trouble — problems that aren’t easy to solve. 

Running two cycles of iterations means you’ve got to deal with: 


LOTS more communication 

Now, not only do you have inter-team communication issues, but you’ve got two teams 
trying to work together. The testing team will have questions on an iteration, especially 
about error conditions, and the development team wants to get on to the next story, not 
field queries. One way to help this is to bring a representative from the test team into 
your standup meetings as an observer. He’ll get a chance to hear what’s going on each 
day and get to see the any notes or red stickies on the board as the iteration progresses. 
Remember that your standup meeting is your meeting, though — it’s not a time to 
prioritize bugs or ask questions about how to run things. 
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Testing in a FIXED iteration length 

If you’re keeping your two iteration cycles in sync — and 
that’s the best way to keep the testing team caught up — 
you’re forcing testing to fit into a length that might not be 
ideal. To help give the test team a voice in iterations, you 
can have them provide you a testing estimate for stories 
you’re planning on including in your iteration. Even if you 
don’t use that to adjust what’s in your iteration (remember, 
you’re priority-driven) it might give you some insight into 
where the testing team might get hung up or need some 
help to get through a tough iteration. 



I teams a^d 祕⑽七 
- tW，s ^ be ^ 


328 Chapter 9 











ending an iteration 


Fixing bugs while you keep working 

The development team will start getting bug reports on 
their first iteration about the time they’re getting into the 
third iteration! And then you have to figure out if the bug’s 
important enough to fix right away, roll into the current 
iteration, or put off for later. We’ll talk more about this in a 
minute, but the straightforward approach is to treat a bug 
like any other story. Prioritize it against everything else and 
bump lower-priority stories if you need to in order to get it 
done sooner. 


Another approach is to carve off a portion of time every 
week that you’ll dedicate to bug fixes. Take this off of the 
available hours when you do your iteration planning, so 
you don’t need to worry about it affecting your velocity. For 
example, you could have everyone spend one day a week on 
bug fixes — about 20% of their time. 
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Writing tests for a moving target 

Functionality in user stories — even if it’s agreed upon by the customer — can change. So lots of 
times, tests and effort are being put into something that changes 30 days later. That’s a source 
of a lot of irritation and frustration for people working on tests. There’s not much you can 
do here except communicate . Communicate as soon as you think something might change. 
Make sure testing is aware of ongoing discussions or areas most likely to be revisited. Have 
formal turnover meetings that describe new features and bug fixes as well as known issues. One 
subtle trick that people often miss is to communicate how the process works. Make sure the testing 
team understands to expect change. It’s a lot easier to deal with change if it’s just part of your 
job rather than something that’s keeping you from completing your job. 
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enabling communication 


But this is the same sort of stuff we 
were dealing with anyway, right? Theres 
nothing really new here... 


o 


More iterations really just means 
more communication. 

During an iteration there are some messy 
things to deal with: multiple team members, 
your customer changing requirements and 
user stories, priorities of different pieces of 
functionality, and sometimes having to guess 
at what you’re going to build before your 
requirements are complete. 

Adding another cycle of iterations 
might mean more of the same issues, 
but you won’t have any new ones. ’ 

That means you can rely on the 
same things you’ve already been doing: standup 
meetings, tracking everything you do on your 
big board, using velocity to account for real life, 
and lots and lots of communication — with your 
team, with the testing team, and, of course, with 
your customer. 







Tke key to most problems you’ll 
run into in software development is 

CQMMUNflCATIQV. 

Wken in ctouLt，TALK to your team, 
otker teams，and your customer. 
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ending an iteration 


(^Sharpen your pencil 


Below are some different approaches to testing, all of which 
involve just one cycle of iterations. What are some good things 
about these approaches? What are some bad things? 
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effective system testing 


c^Jharpen your pencil 

Solution 


Below are some different approaches to testing, all of which 
involve just one cycle of iterations. What are some good things 
about these approaches? What are some bad things? 
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ending an iteration 


Top 10 
Traits of 
Effective 
System 
Testing 



Good，frequent communication between the customer, 
development team, and testing team. 


9 


Know the starting and ending state of the system. Make 
sure you start with a known set of test data, and that the data ends up 
exactly like you’d expect it at the end of your tests. 


8 Document your tests. Don’t rely on that one awesome tester 

who knows the system inside and out to always be around to answer 
questions. Capture what each tester is doing, and do those same things 
at each round of system testing (along with adding new tests). 



Establish clear success criteria. When is the system good enough 
to go live? Testers can test forever — know before you start what it 
means to be finished. A zero-bug-bounce (when you get to zero 
outstanding bugs, even if you bounce back up after that) is a good sign 
you’re getting close. 


6 Good，frequent communication between the customer, 
development team, and testing team. 


5 Automate your testing wherever possible. People just aren’t 

great at performing repetitive tasks carefully, but computers are. Let the 
testers exercise their brains on new tests, not on repeating the same five 
over and over and over again. 


4 A cooperative dynamic between the development team and 
testing team. Everyone should want solid, working software that they 
can be proud of. Remember, testers help developers look good. 


3 A good view of the big picture by the testing team. Make sure 
that all your testers understand the overall system and how the pieces fit 
together. 


2 Accurate system documentation (stories, use cases, requirements 
documents, manuals, whatever). In addition to testing docs, you should 
capture all of the subtle changes that happen during an iteration, and 
especially between iterations. 


I Good，frequent communication between the customer, 
development team, and testing team. 
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filing and fixing a bug 


The life (and death) of a bug 

Eventually, your testers are going to find a bug. In fact, 
they’ll probably find a lot of them. So what happens 
then? Do you just fix the bug, and not worry about it? 
Do you write it down? What really happens to bugs? 
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O The tester FILES A BUG REPORT 


This is one of the most critical steps: 
have to track bugs! It doesn’t matter who 
reports a bug, but level of detail is crucial. 
Always record what you were trying to do, and 
if possible, the steps to re-create the bug, any 
error messages, what you did immediately 
before the bug occurred, and what you would 
have expected to happen. 


o 


A tester FINDS A BUG 

A bug doesn’t have to be something that’s clearly failing. 
It could be ambiguity in the documentation, a missing 
feature, or a break from the style guide for a web site. 


o UPDATE the bug report 

Once the tester (and original reporter) 
are happy with the fix, close the bug 
report. The updated report can be 
used as a script to retest. Don’t delete 
it...you never know when you might 
want to refer back to it. 



334 Chapter 9 











ending an iteration 
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CREATE A STORY (or task) to fix the bug 

Bugs are just work that has to be done in your 
system — sometimes in the current iteration, 
sometimes in a later one. You’ll need to capture them 
and prioritize each bug with the customer. These are 
tricky to estimate, though, because it’s not always 
clear what’s wrong. Some teams have a “Bug Fix” 
story that they just keep around, and they add tasks 
to it as needed. 
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FIX THE BUG 

The development team works on the bug as part 
of an iteration. Start by writing a test that exposes 
the bug (the test should fail before you change any 
code). Once the team’s fixed the bug (and the test 


CHECK THE FIX and verify it works 

The tester (or original reporter) verifies the new build 
and makes sure they’re happy with the resolution. 
Now the bug can be marked as closed (or verified). 


lets you know when that is), they should mark it 
as “Fixed” in the bug tracker. But don’t mark it as 
tested, closed, or verified 一 that’s for the original 
reporter to take care of. This also helps you get a 
list of what’s ready for turnover to the test team. 
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bug trackers 


So you found a bug.... 

No matter how hard you work at coding carefully, some bugs are going to 
slip through. Sometimes they’re programming errors; sometimes they’re just 
functional issues that no one picked up on when writing the user stories. Either 
way, a bug is an issue that you have to address. 


?ugs belong \v\ a bug tracker 

The most important thing about dealing with bugs on 
a software project is making sure they get recorded 
and tracked. For the most part it doesn’t matter which 
bug tracking software you use; there are free ones 
like Bugzilla and Mantis or commercial ones like 
TestTrackPro and Clear Quest. The main thing is to 
make sure the whole team knows how to use whatever 
piece of software you choose. 

You should also use your tracker for more than just 
writing down the bug, too. Make sure you: 


o 


❺ 


Record and communicate priorities 

Bug trackers can record priority and severity information tor dl 
O ne way to work this in with your board is to pick a priority level — say 
priority 1, for example — and all bugs of that priority level get turned 
into stories and prioritized with everything else for the next iteration. 
Any bugs below priority 1 stay where they are until you’re out of priority 
1 bugs. 

Keep track of everything 

Bug trackers can record a history of discussion, tests, code changes, 
verification, and decisions about a bug. By tracking everything, your 
entire team knows what’s going on with a bug, how to test it, or what the 
original developer thought they did to fix it. 
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Generate metrics 

Bug trackers can give you a great insight into what’s really going on with 
your project. What’s your new-bug submission rate? And is it going up or 
down? Do a significant number of bugs seem to come from the same area 
in the code? How many bugs are left to be fixed? What’s their priority? 
Some teams look for a zero-bug-bounce before even discussing a 
production release; that means all of the outstanding bugs are fixed (bug 
count at zero) before a release. 

^^ v^cll talk move about dclW —吒 
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ending an iteration 


Awatomy of a bug report 

Different bug tracking systems give you different templates for submitting a bug, but 
the basic elements are the same. As a general rule of thumb, the more information you 
can provide in a bug report, the better. Even if you work on a bug and don’t fix it, you 
should record what you’ve done, and any ideas about what else might need to be done. 

You — or another developer — might save hours by referring to that information when 
you come back to that bug later. 

A good bug report should have: 

Summary: Describe your bug in a sentence or so. This should be a detailed action 
phrase like “Clicking on received message throws ArrayOutOfBoundsException，” 
not something like “Exception thrown.” You should be able to read the summary 
and have a clear understanding of what the problem is. 

Steps to reproduce: Describe how you got this bug to happen. You might not 
always know the exact steps to reproduce it, but list everything you think might have 
contributed. If you can reproduce the bug, then explain the steps in detail: 

1. Type “test message” into message box. 

2. Click “sendlt.” 

3. Click on the received message in the second application. 

What you expected to happen and what really did happen: Explain 
what you thought was going to happen, and then what actually did happen. This is 
particularly helpful in finding story or requirement problems where a user expected 
something that the developers didn’t know about. 

Version, platform, and location information: What version of the software 
were you using? If your application is web-based, what URL were you hitting? If 
the app’s installed on your machine, what kind of installation was it? A test build? A 
build you compiled yourself from the source code? 

Severity and priority: How bad is the impact of this bug? Does it crash the 
system? Is there data corruption? Or is it just annoying? How important is it that the 
bug gets fixed? Severity and priority are often two different things. It’s possible that 
something is severe (kills a user’s session or crashes the application) but happens in 
such a contrived situation (like the user has to have a particular antivirus program 
installed, be running as a non-Administrator user, and have their network die while 
downloading a file) that it’s a low-priority fix. 

r- 厶… - 

What else would you want to see in a bug report? What kind of information would 
you want to see from the user? How about any kind of output from the system? 
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learn from your iteration 


Put there's still plenty 
left you COUIP do... 

So you’ve handled system testing and dealt with the major 
bugs you wanted to tackle this iteration. Now what? 


Whctt We (fcrrt KaVe 


□ 

□ 

□ 


Process improvements 

System testing 

Review the iteration for what worked 
and what didn’t 


& 苑 SI 


Refactor code using lessons you’ve learned 

Code cleanup and documentation updates 

More design patterns? 

Development environment updates 

R&D on a new technology you’re 
considering 

Personal development time to let people 
explore new tools or read 


Tke rigfkt tiling 

to cto at any 
time on your 
project is tke 
rigkt tiling to 

Jo AT THAT 
TIME on 

YOUR project. 


A good software process is all about prioritization. You want to make sure 
you’re doing the right thing on the project at all times. 

Producing working software is critical, but what about quality code? Gould you 
be writing even better code if your process was improved? Or if you dropped a 
couple thousand lines by incorporating that new persistence framework? 


Thc\rc a\rc Y\o 
h3v*d—Pas-t 
vules — you’ve got 

io r^akc this 
de^isioh youv-sd-f. 
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E%eftclSe 


Below are three burn-down graphs. It's up to you to decide what to do next. 
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different project hurdles 



Below are three burn-down graphs. It's up to you to decide what to do next. 
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ending an iteration 



How can you decide what to do next when you 
haven’t even seen the code the team is working on? 


o 


Each project is different...sort of. 

Remember, software development isn’t about just 
code. It’s about good habits and approaches to 
deliver working software, on time and on budget. 
Besides, we already have: 




Compiling code 


d 

Bf 


Automated unit testing 

User stories and tasks that capture 
what needs to happen 

A process for prioritizing what gets 
done next 

A working build of the software 
we can deliver to the customer 


So this is about how to prioritize additional, nice- 
to-have tasks, if you’ve got extra time. And that’s 
all about where you are in your project. Early 
on you’ll likely need more refactoring to refine your 



design. Later, when the project is a little more stable, 
you’ll probably spend more time on documentation 
or looking at alternatives to that aging technology the 


team started with six months ago. 
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iteration reviews 


Time for the iteration review 


It’s here: the end of your iteration. You’re remaining work is at zero, 
you’ve hit the last day of the iteration, and it’s time to start getting ready 
for the next iteration. 

But, before you prioritize your next stories, remember: it’s not just 
software we’re developing iteratively. You should develop and define your 
process iteratively, too. At the end of each iteration, take some time to do 
an iteration review with your team. Everyone has to live with this process 
so make sure you incorporate their opinions. 


Elements of m iteration review 





Prepare ahead of time 

An iteration review is a chance for the team to give you their input on how 
the iteration went, not a time for you to lecture. However, it’s important to 


keep the review focused, too. Bring a list of things you want to make sure get 


discussed and introduce them when things start wandering off. 





Be forward-looking 

It’s OK if the last iteration was tragic or if one if the developers consistently 
introduced bugs, as long as the team has a way to address it in the next 
iteration. People need to vent sometimes, but don’t let iteration reviews turn 
into whining sessions; it demoralizes everyone in the end. 


Calculate your metrics 

Know what your velocity and coverage were for the iteration that just 
completed. In general, it’s best to add up all of the task estimates and 
divide by the theoretical person-days in your iteration to get your velocity. 
Whether or not you reveal the actual number during the review is up to you 
(sometimes it helps to not give the actual number just yet so as not to bias any 
upcoming estimates), but you should convey whether the team’s velocity went 
up or down. 

Have a standard set of questions to review 

Have a set of questions you go through at the end of each iteration. The 
set of questions can change if someone would like to add something or 








\YX 


a question really doesn’t make sense for your team. Having recurring 
discussion topics means people will expect the questions and prepare (even 
unconsciously during an iteration) for the review. 
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ending an iteration 


Some iteration review questions 

Here is a set of review questions you can use to put together your first 
iteration review. Add or remove questions as appropriate for your team, 
but try to touch on each of the general areas. 


Itercition fieVfeW Questions 



Is everyone happy with the quality of work? Documentation? Testing? 

How did everyone feel about the pace of the iteration? Was it frantic? 
Reasonable? Boring? 

Is everyone comfortable with the area of the system they were working in? 


Are there any tools particularly helping or hurting productivity? Are there 
any new tools the team should consider incorporating? 


Was the process effective? Were any reviews conducted? Were they 
effective? Are there any process changes to consider? 

Was there any code identified that should be revisited, refactored, or 
rewritten? 


㈣ 




Were any performance problems identified? 


Were any bugs identified that must be discussed before prioritization? 


Was testing effective? Is our test coverage high enough for everyone to 
have confidence in the system? 

Is deployment of the system under control? Is it repeatable? 


Any of these questions could turn into things you’d like to get done next 
iteration. Remember, you should be story-driven, so make sure any changes 
you want to introduce support some customer need (either directly or 
indirectly) and get prioritized along with everything else. It might mean you 
need to make a case for a technology or process change to the customer, but it’s 
important to remember why you’re writing the software in the first place. 
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other things to do 


getting EXTRA things done. 


You’ve got to figun| 
but here are some 
you’ve got extra ti: 


out what’s best for your project, 
general things you can look at if 
e in your iteration. 


H 




Fix bugs 

Obviously this depends on what your bug backlog looks like. Remember to 
prioritize bugs with the customer, too. There might be some bugs that are 
vital to the customer, and others they just don’t care that much about. 

Pull iw stories that are ow deck for next iteration 

Since the customer has prioritized more stories than typically fit in an iteration, 
you can try pulling in a story from the next iteration and get working on it now. 
Be careful doing this, though, as the customer’s priorities or ideas for the story 
may have changed during your iteration. It’s also good to make sure you know 
whether or not the test team has time to test any extra stories you pull in. 

Prototype solutions for the next iteration 

If you have an idea about what’s likely coming in the next iteration, you 
might want to take advantage of an extra day or two to start looking 
ahead. You could try writing some prototype code or testing technologies 
or libraries you might want to include. You probably won’t commit this 
code into the repository, but you can get some early experience with things 
you plan on rolling into the next iteration. It will almost certainly help your 
estimates when you get back to planning poker. 

training or learning time 

This could be for your team or for your users. Maybe the team goes to a 
local users group’s session during work hours. Get a speaker or technology 
demo setup. Run a team-building exercise like sailing or paintball. Care 
and feeding of your team is an important part of a successful project. 
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ending an iteration 


Seriously, do people ever really 
have time at the end of the iteration? 

Yes, absolutely! It usually goes 
something like this: The first iteration or two 
are bad news. People always underestimate 
how long something is going to take early 
on. At the end of each iteration, you adjust 
your velocity, so you end up fitting less into 
subsequent iterations. As the team gets 
more experienced, their estimates get better, 
and they get more familiar with the project. 
That means that the velocity from previous 
iterations is actually too low. This ends up 
leaving room at the end of an iteration—at 
least until you recalculate the team’s velocity. 
And believe it or not, sometimes, well, things 
just go right and you have extra time. 

Wait, you said the first two 
iterations will be bad? 

You don’t want them to be, but realize 
that people almost always underestimate 
how long things will take—or how much 
time they’re spending on little things that 
no one is thinking about, like setting up 
a co-worker's environment or answering 
questions on the user’s mailing list. 

Those are all important things, but need to 
be accounted for in your work estimates. 
That’s part of why a velocity of 0.7 for your 
first iteration is a good idea. It gives you 
some breathing room until you really know 
how things are going. You'll be surprised 
how fast you can fill an iteration with user 
stories, too. Strike a balance between 
getting a lot squeezed in and being realistic 
about what you can hope to get done. 


there ^ are no o 

Dumb Questi9ns 


We seem to always have extra time 
at the end of our iterations—and lots of it. 
What’s going on? 


C^: You keep saying to prioritize bugs... 
but we’re in the middle of an iteration. So 
how do bugs fit in? 


One idea is that your velocity might 
be way off. Are you updating it at the end of 
each iteration? (We’ll talk more about that in 
the next chapter) Another idea is that your 
estimates are off—on the high side. If you’ve 
recently had an iteration where things got 
really tight at the end, people will naturally 
be more conservative in their estimates in 
the next iteration. That’s OK, though. If you 
have lots of time, pull in another story or two 
at the end of the iteration, and when you 
update your velocity it will all balance back 
out. 

We tried pulling a story into our 
iteration, but now it’s not finished and 
we’re just about out of time. 

Punt on the story. Remember, you’re 
working ahead of the curve anyway. It’s 
better to punt on the story and put it back 
into the next iteration than it is to commit half- 
written, untested code and just “wrap that 
up” next iteration. Remember, you’re going 
to send your iteration’s build out into the wild. 
You want it as stable and clean as possible. 

If there is extra time at the end of an iteration 


Some projects have regularly 
scheduled bug reviews with the customer 
once a week or so to prioritize outstanding 
bugs. In those cases, there’s always a pool 
of work to pull from if there’s time available. 

If you don’t meet with your customer to talk 
about bugs regularly, you might want to think 
about that...although be sure to factor in the 
time you’ll spend on your burn rate and big 
board. Remember, if the bug is sufficiently 
important to fix, it should get scheduled into 
an iteration like anything else. 

It’s important to note we’re talking about 
bugs found outside of developing a story. If 
you find a bug in a story you’re working on, 
you should almost always fix it (after adding 
a test!). Nothing is “done” until it works 
according to the story—and the tests are 
proving it. 

You skoulctnt liave 

LOTS ol time lelt 

over. So ckoose 

SMALL TASKS 


some teams will tag their code before 
they pull anything else into the repository. 
That way, if things go south, they have no 
problems releasing a stable build by using 
the tag. 


to take on witk any 
extra time you liave … 
and get ready lor 
tke NEXT iteration. 
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Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter, 
you learned how to end an iteration effectively. 

For a complete list of tools in the book, see 
Appendix ii. 


Pav bo your \>^Ao^ 

C s ? e 6 *,allv iWat.o, „ds 

sW«es ^ you ^cd ^ A 3°'^ 

po〆 七 — A ^\t U ^ 

carlv-^ stuW v/orks, let 

use time to aV^cad ov 

\ t ^\rY\ sowtWiy^ v\cw 


tteve 扣 c some 

key 

y° u leaded ih 


..arvdl so«>c o( 

卜 6 咖 bcWmd 


P^,ui ples 


li^aiio^s aire a way h> impose 
ihtcvmcdiatc dcadlihcs-sti^k -to th 

Always estimate ^ the ideal day 
七 he "tc3m 


Cm 


^ the bi 9 pidWc ih mihd whCh 
P ,ahhih 9 •• 七 MtiohS — 如 d that might 
ihdudc ^sti h g the syst^ 

Uphove y ou ^ piro^ss iW.v C |y though 
i 七 eva 七 ioh \rcviews 


BULLET POINTS - 

■ If you have some room at the 
end of an iteration, that’s a 
good time to brainstorm for 
new stories that might have 
come up. They’ll need to be 
prioritized with everything else, 
but it’s great to capture them. 

■ Resist the temptation to 

forget about all of your good 
habits in the last day or two of 
an iteration. Don’t just “sneak 
in” that one quick feature that 
has a low priority because you 
have a day or make that little 
refactoring that you’re “sure 
won’t break anything ■” You 
worked really hard to get done 
a day or so early, don’t blow it. 

■ Work hard to keep a healthy 
relationship with your testing 
team. The two teams can 
make each other miserable if 
communication goes bad. 

■ Recording actual time spent on 
a task versus estimated time 
on a task isn’t necessary since 
your velocity will account for 
estimation errors. But, if you 
know something went really 
wrong, it’s worth discussing 
in the iteration review. 
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ending an iteration 



Iterationcross 

You’ve reached the end of your iteration. Take a 
breather and enjoy a nice crossword puzzle. 



Across 

4. Estimate for the.day and the.team member. 

5. Pay attention to your.rate to help understand how 

your team is doing. 

6. Make sure your testing team understands the. 

9. Standup meetings are about. 

11. Try really hard to end an iteration. 

12. A quick and dirty test implementation is a.solution. 

13. System testing is usually.testing, but 

sometimes.testing. 


Down 

1. Since testing can usually go on forever, make sure you 
have this defined and agreed to by everyone. 

2. When your bug fixing rate exceeds your bug finding rate for 
awhile. 

3. You should estimate consistently because random 

disruptions are included in your. 

7. A good way to work through a bug backlog is to treat them 
as. 

8.system testing whenever possible. 

10. System testing should really be done by a.team. 
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crossword solution 



Iterationcross Solution 
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10 the next itercltion 



l/it aWt broke 


ou still better fix it 


So then he said, I dont wont 
to wear a white shirt this time; I 
want to wear a blue shirt/ 1 How am I 
supposed to react to that? 




Think things are going well? 

Hold on, that just might change... 

Your iteration went great, and you’re delivering working software on time. 
Time for the next iteration? No problem, right? Unfortunately, not right at 
all. Software development is all about change, and moving to your next 
iteration is no exception. In this chapter you’ll learn how to prepare for the 
next iteration. You’ve got to rebuild your board and adjust your stories 
and expecations based on what the customer wants NOW, not a month ago. 


this is a new chapter 






an iteration finishes with more than code 


What is working software? 

When you come to the end of an iteration, you should have a 
buildable piece of software. But complete software is more than just 
code. It’s also... 


...completing your iteration's work 

You’re getting paid to get a certain amount of work done. No matter 
how clever your code, you’ve got to complete tasks to be successful. 


Voy/y\ 


TVmgs might have looked 
a bit skeUhy at the 



..W 七 Or\o^s (MoVb 
|y a \)\i 


Sowct^cs a 

oyood 

(jiocs^ t cv\d 

oyc-ts 

dov\c，a 叫 

a 种七 

oVCVWAirv- 


Pays Ic-f-b 



/ou: buv-h-dowh Y-aie, as well as the 
^st youv^ big bc^d, 辦 — 

'^d.^Ws how youir itevatioh wchi 
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the next iteration 


passing all your tests 


Unit tests, system tests, black- and white-box tests...if your 
system doesn’t pass your tests, it’s not working. 



File Edit Window PleaseWork 


hfsd> java -cp junit.jar;. org.junit.runner.JUnitCore 

headfirst.sd.chapter7.Tes tRemo teReader 
JUnr version 4.3.1 

Ti : 97.825 


(112 tests) 


h£sd> 


..satisfying your customer 

Software that does what it’s supposed to do, in the time you 
promised it, usually makes customers pretty excited. And in lots 
of cases, it means you’ve got another iteration’s worth of work. 








What would you do to get 
going on the next iteration? 
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planning the next iteration 


You need to pjaw for the wext iteration 

Before diving into the next iteration, there are several things that 
all play a crucial part in getting ready. Here are the key things to 
pay attention to: 

Additional usev s-fcov-ies 


Title ： Choose seating 


Description: A UW Will be 


able to choose aisle or window I 

seating. 

Est： . ..|.5 . Priority: 



"TV^C C.us*bow»CV Will 代一 
usev- sW>cs, 

and pvokaklY add sow>c 

y\c^ ones, *too. 


Bugs -that haver / 七 

dkeddy bcc 灼 v/oirked 
nvto youv- development 
have -fco be demsideved; 
some will end up as tasks 

i 灼 "the itcira-tioh. 


Buy 



l/clodi-ty 

? 




Hoy ； fas 七 y ou av> d 
Y<>uV 'tcSw' 30 七 
七七 he v/ov^ 

for |*tcv-a*t'ioy\ 

I affetis Y ouV " 

Mt\oC\bi 

-fov- |*tcv-a*t'ioy\ 2-. 


The next 

xt^raflen 



Buyy\ 




|«5 10 

pa^s \t^ 


-to co^t up wi-th a 
hCW boavd 4v- the 

itev-atioh, ihdudihg d 
•fresh buv*h-dowh Ydit, av\d 
hCW veUity ^l^ula-tioh. 




use\r siories 




Lca^s you^vc al 代 ad”o 七 ， c f W 咖 
shores ayvd tasks -to *tU about- 

there^ are no ^ 

Dumb Questions 



So what happend to the board from Iteration 1? 

J\i Once the iteration is finished, you can archive everything on the 


old Iteration 1 board. You might want to take a photo of it for archival 
purposes, but the important thing is to capture how much work you 
managed to get through in the iteration, how much work was planned, 
and, of course, to also take any user stories that ended up in the “Next” 
section back into the pack of candidate user stories for Iteration 2. 
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the next iteration 


We can fit more user stories in this next 
iteration, right? We should have gotten over a 
lot of setup stuff, and understand the overall 
app better now, right? 



Recalculate your 
estimates and 
velocity at eack 
iteration, applying 
tke tkings you 
learned Irom tke 


You need to revise your story and task 
estimates and your team’s velocity. 

When originally planning Orion’s Orbits, you and 
your team came up with estimates for each of the user 
stories for Version 1.0, and then the tasks associated 
with each of those user stories. Now that it’s time 
to kick off another iteration, you have a lot more 
knowledge about how things will work. So it’s time to 
revisit those estimates for the remaining user stories 
and tasks. 

Also, when you originally calculated how much work 
you could complete in the first iteration, you didn’t 
know how fast your team could develop software and 
complete their tasks. You probably used an initial value 
of something like 0.7 for your team’s velocity. Butthat 
was just a rough guess...now, you and your team have 
completed an iteration. That means you’ve got hard 
data you can use for recalculating velocity, and getting 
a more accurate figure. 

Remember, your estimates and your velocity are about 
providing confident statements to your customer about 
what can be done, and when it will be done. You 
should revise both your estimates and your velocity at 
every iteration. 


previous iteration* 


Velocity a 仏 ouhts 

fo\r overhead ih youv- 
estimates. A value 
<^P 0.1 says -that 
you expert 10 % o-f 
you\r teams tir^c io 
be SpCht Oh otlicv* 
things thah the 
actual dcvcloprwcht 
wo\rk. Flip ba^k -to 
Chaptcv -1 u rwo\rc 
oh velocity. 


you are here ► 


353 





building your board for the next iteration 



E%enciSe 


It’s time to plan out the work for another iteration at Orion's. First, calculate your team’s new 
velocity according to how well everyone performed in the last iteration. Then, calculate the 
maximum amount of days of work you can fit into this next iteration. Finally, fill out your project 
board with user stories and other tasks that will fit into this next iteration using your new 
velocity, the time that gives you, and your customer's estimates. 


❶ 


Calculate your new velocity 

Take your team’s performance from the previous iteration and 
calculate a new value for this iteration’s velocity. 


/ (zo % 


丫 歧 七 0’ s 
y\cvj vclo 6 *ty- 


Nurwbcv* of 
actual y/ovk’mg 

days \y\ -the 
Iasi iicv-aiioh. 


o-f dcvclofcvs 
oy \ youv 'tcaw' 

七 he bs 七 

•rtevatio 灼 . 


This is *thc -total 
days o( wovk you 
addomplished, based 
oy\ what you ad*tu3lly 
domplc-tcd. 

used 

© 抑 

Calculate the work days you have available 

Now that you have your team’s velocity, you can calculate the 
maximum number of work days that you can fit into this iteration. 





% 


Tiic r>urr>bcv of 
people oy \ youv *tc3» 



The hCX-t i-tc\ratioh 
is a rwohtli loh^ 
agaih, so that’s ZO 
^alchdav-y days 


丁 he hCw velocity 
you just ^a^ula-tcd 


T\)t amourrt of v/ovk, 
•m days, i\\ai youv 
•team ddr> handle m 
*tK*is *rtcv-atiov> 
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the next iteration 


❺ 


Fill up the board with new work 

You know how many work days you’ve got, so all that’s left is to take the candidate 
user stories and bugs, as well as stories left over the last iteration, and add them to 
your board — make sure you have a manageable workload. 



Rcv/\riic ihc wov-k 
days you’ve goi 
available - doh’t 

ovcvvuh -this/ 

u 


Title: 


Choose scatmg 


Est ： . .1.*^ 'day? 
Priority: .xo... 


The dus^torncv has 
pnoH-tiz^cd av\d you 浐 
team played pbrmmg 
fokc\r -to \rc-cs-tirwatc. 


Ti« e : . . Fix date 

Est ■- . 7 . 

Priority ： 


st: .7 今 .. 

riority ： . . lO 


bu^ -f'rom 七 he 
last i*tcv-a*tior\ 


^.bookihg 


彻一 — /hYPal 

. 

.. 


Order iw-flight weals 


Title:. 

Est: . JI.cIay 


Priority: 


S 


Title:. 

Est: 召 day 


Review flight. 


Priority: 


3 . 0 . 


thc ^ 


User sW»e s 


Title:. 

Est ： . 19. days 


Manage special offers 


I 


Priority: 


. 1 . 0 . 


1 





Plate youv 
sclcttcd usc\r 
s*tovics -fov *biic 
Y\t%i itcv-atio^ 
oy\ youv boavd- 

Wi 七 e down how 
mdy\Y days wo\rk 
youv iWaticw 
\rcsul*b m- 


一一一 - 一 〆 







-- L : m 二： 


: Clratioh s boav^d 
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building your board for the next iteration 



E%enciSe 


Your job was to calculate your team’s new velocity, the maximum amount of days of work you 
can fit into the next iteration, and then to fill out your project board with user stories and other 
tasks that will fit into this next iteration. 


❶ 


Calculate your new velocity 

Take your team’s performance from the previous iteration and 
calculate a new value for this iteration’s velocity. 


30 / (ZO % 


r 

You go-t days o( wov-k dov\c, 
ih^ludihj uhpbhhcd tasks that 
hit the boat'd. 


❹ 


Remember, Mt\oC\bf IS 3 measure 
V^ov/ -fast you a^d w -team 

yt y/ov-k oy\ youv- boavd. 

Rcjav-dlcss o( wV)c*tV^cv" work 

is flawed or r\o*t, i*t all co\ay\^ 


Calculate the work days you have available 

Now that you have your team’s velocity, you can calculate the 
maximum number of work days that you can fit into this iteration. 



/ouv- "teams Mt\oC\bj 

has at-tually droned- 





% 




as has *tKc io-tal 
3r«ouy>*t o( >wovk 七 ha 七 
youV 

v\t%i •• 七 eva 七 iojtv 
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the next iteration 


0 棚 — hnewwork 

You know how many work days you’ve got, so all that’s left is to take the candidate 
user stories and bugs, as well as stories left over the last iteration, and add them to 
your board — make sure you have a manageable work load. 




u 



T\\t y/ovk \rc<\u'i\rcd 

(or *bV^c wt 

i 七 evatio 灼 did〆 七 
c%dccd 七 he 
available ^ days 




Title: Choose scatmg 

Est ： . .1.?. day?. 

Priority: . .^rO . 


These sWics dropped ^ ci-thcv- 
bcddusc they >wcv"C d lowcv* p\riovi"ty 
o\r wouldh^t -Pit withih the wov»k 
days Ic-Pt ih the itev-atioh. 


Order iw-flight weals 

Title:. 

Est ： ..ll.dAys. 

%0 

Priority:. 


Uscv^ sW»CS 


Title: 

Est ： .Uday? 


Manage special offers 


These stov-ics had 七 he 
hi^cs*t priority. 


Title: 


Fix dat.e.QW.bQokmg 




Est: 


PriorH 


?aY wHhV^/MC/PaY?al 

... 

^ (ia'/s. (k 狂 ) . 

10 . 


;W”as W 仰•、严 7 

to tv^c tusto^cv-, SO 




Title: 

Est: 召 days. 

Priority: .… IQ 


Review flight. 


rtwaW. 
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factoring in real velocity 


A team velocity of 0.6!? That’s 
even slower than before. What happened? 

Based on the work done in the last 
iteration, it turned out that your team was 
actually working a little slower than 0.7. 

Shouldn’t my velocity get quicker 
as my iterations progress? 

Not always. Remember, velocity is a 
measure of how fast your team can burn 
through their tasks, and 0.7 was just an 
original rough guess when you had nothing 
else to go by. 

It’s not uncommon for you and your team to 
have a tough first iteration, which will result 
in a lower velocity for the next iteration. But 
you’ll probably see your velocity get better 
over the next several iterations, so you’ve 
got something to look forward to. 

Hmm, I noticed that some of the 
estimates for the Orion’s Orbits user 
stories have changed from when we last 
saw them in Chapter 3. What gives? 

Good catch! Based on the knowledge 
that you and your team have built up in the 
last iteration, you should re-estimate all your 
stories and tasks. Now you know much more 
about the work that will be involved so new 
estimates should be even more accurate, 
and keep you from missing something 
important, and taking longer than you expect. 



So the estimates for our user 
stories and their tasks will get smaller? 

Not necessarily. They could get smaller, 
or bigger, but the important thing is that they 
will likely get more and more accurate as 
you progress through your iterations. 

I see that bug fixing is also 
represented as a user story. Doesn’t that 
break the definition of a user story a bit? 

A little, but a user story really ends up 
being—when it is broken into tasks—nothing 
more than work that you have to do. And a 
bug fix is certainly work for you to take on. 
The user story in this case is a description 
of the bug, and the tasks will be the work 
necessary to fix that bug (as far as you and 
your team can gauge from the description). 

l，m really struggling coming up 
with estimates for my bugs. Am I just 
supposed to take my best guess? 

Unfortunately, you will be taking a 
best guess. And when it comes to bugs, it 
pays to guess conservatively. Always give 
yourself an amount of time that feels really 
comfortable to you. And remember, you’ve 
got to figure out what caused the bug as well 
as fix it; both steps take time. 

One technique you can use is to look for 
similar bugs in the past and see how long 
they took to find and fix. That information 
will at least give you some guide when 
estimating a particular bug’s work. 


If I have a collection of bugs, how 
do I decide what ones should make it 
into the board and be fixed in the next 
iteration? 

” You don’t! Priority is always set 
by the customer. So the customer sets a 
priority for each of the bugs, and that’s what 
tells you what to deal with in each iteration 

Besides, this approach lets the customer 
see that for each bug that is added to the 
iteration, other work—like new functionality— 
has to be sacrificed. 

The decision is functionality versus bug fixes, 
and it’s the customer who has to make that 
call... because it’s the customer who decides 
ultimately what they want delivered at the 
end of the nexf iteration. 

I understand why the high-priority 
stories made it onto the next iteration’s 
board, but wouldn’t it be a better idea to 
add in another high-priority user story 
that slightly breaks the maximum work 
limit, rather than schedule in a lower 
priority task that fits? 

Never break the maximum working 
days that your team can execute in an 
iteration. That value of 36 days for the 
maximum amount of work your team can 
handle for an iteration of 20 days is exactly 
that: the maximum. 

The only way that you could add more work 
into the iteration is to extend the iteration. 

You could fit in more work if your iteration 
were extended to, say, 22 days, but be 
very careful when doing this. As you saw 
in Chapter 1, iterations are kept small so 
that you can check your software with the 
customer often. Longer iterations mean less 
checks and more chance that you’ll deviate 
further from what your customer needs. 
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the next iteration 


Velocity accounts for... 
the REAL WORLP 

Velocity is a key part of planning out your next iteration. You’re 
looking for a value that corresponds to how fast your team actually 
works, in reality, based on how they’ve worked in the past. 

This is why you only factor in the work that has been completed in 
your last iteration. Any work that got put off doesn’t matter; you want 
to know what was done, and how long it took to get done. That’s the 
key information that tells you what to expect in the next iteration. 

Velocity tells you what your team can 
expect to get done in the NEXT iteration 

Be confident in your estimates 

Velocity gives you an accurate way to forecast 
your productivity. Use it to make sure you have 
the right amount of work in your next iteration, 
and that you can successfully deliver on your 
promises to the customer. 



IYs not that I think we can 
deliver on time anymore...I 
know we can deliver. 




By calculating 
velocity ，you take 
into account 

tke REALITY 

ol kow you 
and your team 
develop，so tkat 
you can plan your 
next iteration lor 

SUCCESS. 
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the customer still rules 


Awd ifs STlll about the customer 

Let’s say you’ve calculated your new velocity. You collected bugs 
and put them all in a bug tracker. You waded through all the piles 
of unfinished and delayed tasks and stories, and had the customer 
reprioritize those along with stories planned for the next iteration. 
You’ve got your board ready to go. 

You still have to go back and get your customer’s approval 
on your overall plan. And that’s when things can go really wrong... 



This looks great, but I've got big news...Weve 
just bought Mercury Meals, the galaxy's premiere in¬ 
space catering company, and we need to integrate 
their ordering system into our code ASAP! Throw out 
everything else; this is top priority now. 


X 




estates W 

變 



VVv/c suddenly got a of 

^ toA ^ you khow ho-thma 
about, it ircpla^cs a lot o( 
v/ha-t you had plahhcd -fov the 
"ext i-tciratioh. 
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the next iteration 



Now hang on a second! That’s a LOT of work 
to just toss out. Couldn’t we have checked with 
the customer earlier? Or done something else 
to avoid all this wasted time? 


Software is still about CHANGE 

Sometimes the customer is going to come up with 
a big change at the last minute. Or your best plans 
break down when your star programmer takes a new 
job. Or the company you’re working for lays off an 
entire department... 

But even though what you’re working on has changed, 
the mechanics of planning haven’t. You have a new 
velocity, and you know how many days of work your 
team has available. So you simply need to build new 
user stories, reprioritize, and replan. 


You already know how to... 


□ 

□ 

□ 


Calculate your team’s velocity 
Estimate your team’s user stories and tasks 

Calculate your iteration size in days of work that 
your team can handle 



You’ve got a ton of new code that you’ve never 
seen or used before. What would be the first thing 
you do to try and estimate the time it will take to 
integrate that code into the Orion’s system? 
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it’s sfi// software 


Someone else's software 
is STlll just software 


Even though the Mercury Meals library is not code you 
have written, you still treat the work necessary to integrate 
the code into Orion’s Orbits as you would any other 
software development activities. You’ll need to tackle all the 
same basic activities: 


User stories 

Every change to the software is motivated by and 
written down as a user story. In this case, your story card 
will be a description of how the Mercury Meals code 
is used by the Orion’s Orbit system to achieve some 
particular piece of functionality. 


toAt- 


Title: .Integral；?, code 

Est ： . days. 

Priority: . 1 0. . 


Estimates 

Every user story needs an estimate. So each of the user 
stories that the Mercury Meals code library plays a part 
in has to be estimated. How much time will it take to 
build that functionality, including time spent integrating 
the Mercury Meals code? 




Priorities 

The final piece of the puzzle is, of course, priorities. Each 
of the user stories associated with the Mercury Meals code 
needs to have an associated priority from your customer 
so that you can plan out the work for the next iteration, in 
the order that your customer wants it done. 



\ 

The Meals toAt 
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the next iteration 





You've got new stories related to Mercury Meals, as well as the stories you thought you’d 
be doing in this next iteration. Your job is to re-create the board using your velocity and the 
customer’s priorities. (We’ve left out the stories that didn’t make the first-pass plan.) 



These y/cv-c the usev- s*to\rics 
made rb o^*to youv board 
■the pass. 



1 

The humbev* o( people 
,h y°^ -team dhd 
theiir velocity hasn't 

sih 匕 e youv 

attempt ai a 
p 呼 d: boavd this 

i*tcV"3*tioh, so hcithcV" 
has "the humbev* 
work days you’ve go-fc. 


Add uf youv- 
-total y/ovk -fo\r *b^c 
i*bcv-a*bio\r\. 
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integration tasks on your board 



Your job was to re-create the board using your velocity and the customer’s priorities. 


E^eiu：tSe 

SoLytlOH 



Order vegetariaw 

Title ： or vcgaw 
Est: . 、鄉 • 

Priority: … ID. 


\\s Mcv-tuv-y /vicais uscv 
stovy v/ds d loy/cv- pv'iovi-ty 
dr\d so Will iidvc *to y/a.rt 

-folloy/'m^ \itrahov\ 





^)u\r Wdyb >m3s 
days y/o\rk -fo' 
youv- team, -fatWmJ 

•m vdotrby … 
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the next iteration 


Customer approval? Check! 


Once again, you’ve got to get customer approval 
once everything’s planned out. And this time, there 
aren’t any surprises... 





This looks great! Ifs a shame we can’t do everything, but 
I’m really excited to see us using the new Mercury Meals 
code. I can’t wait to tell the CFO! I'll let her know right 
now, and I’ll even mention your name. 




Yes,，is really possible h> get ^athoyys like 

this 柊。咖 a 6\ood plahhiha 

+eedb^k is a su,e way b> get you, 

咖 boa\rd cx^i-ted. 


1 



iiiereicire no o 

Dumb Questions 


Can you tell me again why we’ve got user stories for 
working with third-party code? And why did you estimate 12 
days for ordering a meal? Isn’t the whole point of getting third- 
party code that it saves us time? 

A user story isn’t as much about writing code as it is about what 
a user needs your system to do. So no matter who wrote the code, if 
you’re responsible for functionality, capture it as a user story. 

As for why the estimates are pretty large, reuse is great, but you’re 
still going to have to write some code that interacts with the third- 
party software. But just think how long it would take if you had to 
write all the Mercury Meals code yourself. 


C^: Are there any times when I shouldn’t consider reusing 
someone else’s code library or API? 

Reuse can really give your development work a shot in the 
arm, but third-party code has to be used with care. When you use 
someone else’s software, you’re relying on that software, placing 
your success in the hands of the people that developed the code that 
your code now uses. 

So if you’re using someone else’s work, you better be sure you can 
trust that work. 
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integrating third-party code 



It’s time to write the code for the two Mercury Meals user stories, “Order Regular Meals” and “View 
^ \ # all the orders for a flight.” On the left you have the Mercury Meals code’s interface, which is a 

collection of methods that you can call from your own code. On the right, you need to wire up your 
code so that it uses the Mercury Meals API to bring both of the user stories below to life. 


丁 d? 



Title: . . 卵 ㈣ M 叫 1 

Est: ..[%. da.7§. 

Priority: • ...l.o. 


View all the orders 
Tm e: for a flight 
Est: . days 

Priority: • 


Rejli-fcy ^hg^k ： assume youv- "tea 

s J CYyi days 9 c Uih 9 das ： 
diayra^s -fcogethev 

/Wwuiry /Weals API. 


How you get 

3 匕匕 ess "to the 

^lcUu\ry/\/lcsls 


Methods oy\ 

i\\ai ca^ be 
called 

youv* todc 


yW maih -to -the 

^Icdls toAt 


^ Alcir^uvy 


McrduryMcal 


s 




+ ^ctl^s-tantcO : Mcv-turyMcaU ^ ca ^. cs a waA ordtr 

+ ^ate^ae .0 Mtr ^ Subr ^ 叫―。咖 

+ Submi-tOv-dcV-toV-dicv- * Ov-dcv-/ *boolC 3 ^ /VJc^uvy A/lcals 

+ ^C-tMcalOp-tionfnamC : : McalOftion 4 * - ^ Bee/ 

+ ^ct0v*dcvsTli3't/Vl3*ttV>'^cy'wov*(j[s(keY>wovds : S-tv*'m^C3) ： 0ydeyC3 


Rctuv^s a list o( orders 

七 ha 七 ma-Uii a spe^i-f i^ sci o( 

kcy>wo\rds 


Wcv 4 ^c -that 

^pircsch-ts ay\ 
ovdev 4 ir a meal 




Order 


>u 乙 dh add 
optiohs -to dh 

ovdev... 


•••dytdi ddei 
keyv^ovds 七 ha 七 you 
tav\ scav-dii oy\ 
la*tcv *to \rc*tv*icvc a 
sc*t o^c ovdevs. 


+ addA1cal6)p-tioh^calOptior> : Mta\Oyhoy \) : void 
+ adcUscywo\rdfkcywo\rd - : void 
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the next iteration 


4u tBY\ dovmlodd the Alcv-tuv-y Meals Codt -fv-om 


// Adds a meal order to a flight 


. .1 


public void orderMeal (String [] options, Stnng rugn^u ； 

throws MealOptionNotFoundException, 

Tiic Imc cm* dodc iias alvcady 

OrderNotAcceptedException { 


MercuryMeals 


mercuryMeals = MercuryMeals .getlnstance(); 


for (int x = 0; x < options .length;x++) 


Order order = mercuryMeals•createOrder() 


A— ^ode 


order.addKeyword(flightNo); 




lf ( • 脈咖巧他 313 . sub mitO r d er (order)T 

比 咖卿 QrderNQt 处 明咖咖邮 叫虹 加）, • 


MealOption me I 






// Finds all the orders for a specific flight 

public String [] getAllOrdersForFlight (String flight 。） 


if (mealOption != null) { 

order.addMealOption(mealOption); 


else 


throw new MealOp 


tionNotFoundException(mealOption) 
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reuse means trust too 



Your job was to complete the code so that it uses the Mercury Meals API to bring 
both of the user stories to life. 


II... 

II Adds a meal order to a flight 

public void orderMeal(String[] options, String flightNo) 

throws MsalOptionNotFoundException, 

MercuryMeals mercuryMeals = MercuryMeals.getlnstance(); 

Order order = mercuryMeals. createOrder() ， 

bbhk ok-dcv' 

it X = 0 ; X < options.length;X++) - 

if (mealOption != null) { 

order.addMealOption(mealOption) 

} else { 


TW、s ^c-b a 
Mcv-^v-v MeaU 
object for tW»s 

Code ^ st ' 


throw new MealOptionNotFoundException(mealOption); 




- "the 

叩七咖 s sekeied, 

1 hcw 叩仏 h is 

dded {o ih c 

op"tioh iW 七 
•Pouhd, thch av\ 
|cx^cp*tioh is vaised- 
t o\rdcv" as a 


order.addKeyword( flightNo) 


kcyv/o\rd so *tha*b the ov-dev-s -for a pav-ti^ulav 
ri ' 1 1 … s |^^^&ved- 


if ([mercuryMeals.submitOrder(order)) { 

throw new OrderNotAcceptedException(order) 



㈣ t 巧 


7 ⑽ my A] e ak 


// Finds all the orders for a specific flight 

n n • . r i ~ 八如 t\ i i nv'Hcr'o 口门 rFi 1 rrh 廿 f ri ncr f lightNo) 

MercuryMealsmercuryMeals=MercuryMeals^getInstance() 


return 


mercuryMeals.getOrdersThatMatchKeyword({flightNo}) 


Scav^cs 

av>d vcV^ 

ovdevs 

as 

a kc^ oy *^ 


// 































the next iteration 



That was easy. Why did we estimate 16 days for 
integrating the Mercury Meals code? 

There’s more going on here than just integrating code. First 
you and your team will have to come to grips with the Mercury Meals 
documentation. There’ll be sequence diagrams to understand and 
class diagrams to pick through, all of which takes time. Factor in your 
own updates to your design and thinking about how best to integrate 
the code in the first place, and you’ve got a meaty task on your 
hands. In fact, it’s often the thinking time up front that takes longer 
than the actual implementation. 

Does it matter if the third-party code is compiled or not? 

If the library works then it doesn’t matter if it’s in source code or 
compiled form. You have to add in extra time to compile the code if it 
comes as source, but often that’s an easy comand-line job and you’ll 
have a compiled library anyway. 

However, if the library doesn’t work for any reason, then it really 
does matter if you can get at the source or not. If you are reusing 
a compiled library of code then you are limited to simply using that 
code, according to its accompanying documentation. You might 
be able to decompile the code, but if you’re not careful, that can 
mean you are breaking the license of the third-party software. With 
compiled libraries you usually can’t actually delve into the code in the 
library itself to fix any problems. If there’s an issue, you have to try 
and get back in touch with the person who originally wrote the code. 

However, if you are actually given the source code to the library—if 


it’s open source or something that you’ve purchased—then you can 
get into the library itself to fix any problems. This sounds great, but 
bear in mind that in both cases you’re trusting the third-party library 
to work. Otherwise you’re either signing up fora barrage of questions 
being sent to the original developers, or for extra work to develop 
fixes in the code itself. 

What if the third-party code doesn’t work? 

Then your trust in that library quickly disappears, and you 
have two choices: You can continue to persevere with the library, 
particularly if you have the source code and can perform some 
serious debugging to see what is going wrong. Or you can discard 
the library for another, if one’s available, or try to write the code 
yourself, if you know how. 

With any of these options you are taking on extra work. That’s why 
when you consider using third-party code, you have to think very 
carefully. Sometimes that code is forced upon you, like with Mercury 
Meals, but often you have a choice. You need to be aware of just how 
much trust you are putting in that library working. 

Be careful wken ctecictingf to 
reuse sometliingf. Wken you 
reuse code, you are assuming 

tkat code WORKS. 






This is a good time to go grab the code! 

The code for Mercury Meals is available from the Head First Labs site. Just go to 
http://www.headfirstlabs.com/books/hfsd/, and follow the links to download the code 
for Chapter 10. 
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when reuse lets you down 


Testing your code 


Make sure you’ve downloaded the Mercury Meals and 
Orion’s Orbits code from Head First Labs. Make the 
additions shown on page 368, compile everything, and 
give things a whirl... 



p 攸 w 处 . 


a 


m o n 


TerminaJ — bash — 99x23 


> java OrionsOrbits 
Adding order••• 


T 穴 do ^ i look 9 ood...-thc 

^ppl'^tioh hah 9 s. No output, 
ho ^o^rs, ho-thihg... 


fS 


0 


you’re kidding, right? The 
customers CFO got so excited about 
the new improvements, she booked 
herself on the inaugural flight of 
Orion’s Orbits. You re telling me she 
won’t even be able to pick her meal? 
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the next iteration 


Houston wg really do have a problem... 

All that hard work has resulted in a big fat nothing. Your code...or the 
Mercury Meals code... some code isn’t working. Somewhere. And 
your customer, and your customer’s boss, is about to really be upset... 


parpen your pencil 

You’ve 


You’ve just integrated a huge amount of third-party code, and 
something’s not working. Time’s short, and the pressure’s on. 


What would you do? 
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trust no one 


Standup meeting 



Laura: We assumed that the Mercury Meals code 
would work, and it clearly doesn’t, or at least doesn’t in 
the way we expect. What a mess. 

Bob: Well, that sounds like a reasonable assumption to 
me. We would never release code that doesn’t work... 

Mark: Yeah, but that’s us. Who knows what the 
developers at Mercury Meals were doing? 

Laura: We just took the code and assumed it would 
work, maybe we should have tested it out first... 

Bob: So you think the developers at Mercury Meals just 
kicked out a dud piece of code? 

Laura: It certainly looks like it. Who knows if it was 
ever even run, it could have been only half a project. 

Mark: But it’s our code and our problem now... 

Bob: And it’s way too late to start from scratch... 

Mark: ...and we don’t know how the Mercury Meals 
system works anyhow... 


Laura: And worse than all of that, what are we going to 
tell the CFO? Our butts are seriously on the line here... 
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the next iteration 


Trust NO ONE 

When it comes to code that someone else has written, it’s all about trust, and 
the real lesson here is to trust no one when it comes to code. Unless you’ve 
seen a piece of code running, or run your own tests against it, someone else’s 
code could be a ticking time bomb that’s just waiting to explode — right when 
you need it the most. 


When you take on code from a third party, you are relying on that code to 
work. It’s no good complaining that it doesn’t work if you never tried to use 
it, and until you have seen it running, it’s best to assume that third-party code 
doesn’t really work at all. 


Your software...your responsibility 

You’re responsible for how your software 
works. It doesn’t matter if the buggy code in 
the software wasn’t code you wrote. A bug is a 
bug, and as a pro software developer, you’re 
responsible for all the software you deliver. 


It ctoesn’t 

matter wlio 
wrote tlie 


A third party is not you. That might sound a little obvious, but it’s 
really important when you’re tempted to assume that just because you 
use a great testing and development process, everyone else does, too. 


Never assume that other people are 
following your process 

Treat every line of code developed elsewhere 
with suspicion until you’ve tested it, because 
not everyone is as professional in their 
approach to software development as you are. 


code. II it’s 

in YOUR 

software, 

it’s YOUR 

responsibility. 
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looking for problems in reused source code 





The Mercury Meals classes are now your code … but they’re a mess. Circle and annotate all the 
problems you can see in the code below. You’re looking for everything from readability of the 
code right through to problems with functionality. 


// Follows the Singleton design pattern 
public class MercuryMeals 
{ 

public MercuryMeals meallythang; 
private Order cO; 

private String qk = "select * from order-table where keywords like % 1;"; 


public MercuryMeals() { 


public MercuryMeals getlnstance () 

{ 

this.meallythang = new MercuryMeals(); 
return this.instance; 

} 

// TODO Really should document this at some point... TBD 
public Order createOrder { 
return new Order();} 

public MealOption getMealOption(String option) 
throws MercuryMealsConnectionException { 

if (MM.establish().isAnyOptionsForKey(option)) 

{ return MM.establish.getMealOption(option).[0] }; 

return null; 
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the next iteration 


// Mercury Meals class continued... 


public boolean submitOrder(Order cO) 

try { 

MM mm = MM.establish (); 
mm.su(this.cO); 
catch (Exception e) 

{ // write out an error message } return false; } 


public Order[] getOrdersThatMatchKeyword(String qk) 

throws MercuryMealsConnectionException { 

Order o = new Order[]; 
try { 

o = MM•establish()•find(qk, qk); 

} catch (Exception e) { 
return null; 

} 

return o; 

}} 
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finding problems in reused source code 



Your job was to to circle and annotate all the problems you can see in this Mercury Meals code. 


BteftctSe 


(TT Follows the Singleton design pattern 


\io \rcal 


public class MercuryMeals 


TWis 

atbribu 七 e 

is public! 

ThaVs a 


public MercuryMealsC^eallythang 

iVKy is O^rdcv a*t*tv-*ibu*tc? baa 

-fey/ domr«C^*b v/ould Keif - 


f^dodurwCh-tatioh ov\ the dass, othev- -thah 

the that it hr\es io —u ⑶七七 k 
Sihglctoh … 

Ko*t *thc mos*t dcsd\rip*tivc 

- O-f a*t*tv-ibu*tc 


private Order cO ; 七 


ajov~ - privatefstrinq qk = "select * from order-table where keywords like %1 

r\M —- N 

private MercuryMeals instance; ^ Su\rdy this should be d ^ohs-fcolh-t? /\hd does <^k 

wke Ay schsc as ah at-tv-ibu-tc Mme? 


ov-ic 

no—y>o 


/public 

} 


MercuryMeals() 



吻 have a 於 e—6 七⑽如如 
dcdlavcd docs ⑽七 W ，？ 


public MercuryMeals getlnstance() 

{ Wah 9 Oh/ This dlass is supposed -to be 

-- the smgleU patter 

'this . instance = new MercuryMeals () but this looks like it ^v-catcs a hew 

ms-bhde o-P /Wc^u\ry/Wcals cvcv-v -ti^ c 
ihis method is balled - 


return this.instance 



Looks like U/ TODO/Really should document this at some point. . . TBD 

dcvc^r'/P^ 110 0rder createOrder { | TW.s mc^od seems {p A ° 

this bil M. ^ U mdc 山 W, • 七 s a11 oW 如？ 


public MealOption getMealOption(String option) 

throws MercuryMealsConnectionException 

1/Vlvy 灼 。七 

establish - establish () . isAnyOptionsForKey (option)) 

, { return MM. establish () .getMealOption (option) . [ 0 ] 

一 w hu " is ' bad p 以如.，仏 a 

-_ 二 ^ idea V^aisc ah ex 岬七 “ that gives -the 

} mo\rc ih-Po io wov-k with. 


}； 


\us*b or\tc? 
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the next iteration 


// Mercury Meals class continued... 



No do^umcr\*batior\ oy\ *tKis dass s mc*tiiods. 

从 at described M m^ods art 
supposed "to do v/ould make li-fc 3 LOT easier’ 


public boolean submitOrder(Order cO) 

(O >wcmde\r the so^iy/av-c javc r>o mdidaiio^ y/hethev 


try 


This 
This is 


MM mm = MM.establish(); 
mm.su(this.cO); 


catch 


it was y/o\rk'mj o\r v\oi (c^dcft by just 

method sy/allows all c^dcptiohs 七 ha 七 avc v-aised- 
a dldssid c^dcptioh |-p 3^ c^dcptioh yts 

raised, a^d you deal y/i-th i-t legally, then pass 
the oedeptioh up -to the dalles so they at leas 七 
khoy/ y/hat v/cr>*t wv-ohj. 


// write out an error message } return false 


; ( 9 ^ 


丁 he 乙 ode ihdchtol-tioh is s-( ： i|| ^|| 
ov 饮七 k plafic. This makes 七 Uy 
vc\ry hav-d -to v-cad. 


public Order[] getOrdersThatMatchKeyword(String qk) 


throws MercuryMealsConnectionException 


Order o = new Order[]; 


try 


o 


.establish().fin 


catch (Exc^ 1 




e) { 



is bc'mg used hcv-c? This 
does^-t make sc^se, a^d might be a bug. 


return null 


return o 


}} 


Hidm^ c%dcp*tioy>s a^dm| The dallcv- o( 

-this method will wv have -to a 

Mcv-duv-yA1calsCoy>v>cd*t'ioy>£%dCf*tioy> ov 3y>y o*thcv- 
c%dcf*t'ioy> because -this mc*tiiod is hidm^ 

-tKa*t 5 oes y/v-oy>g ar>d jus*t vetuv-^'m^ m\l 


Believe it Olr hoi this bv-adket hcv-c 
乙 loses the dass, but ^v-or, the foov use 
•^dchtatioh, you'd be ha\rd-pv-csscd io be 
su\rc o+ that -Pv-om lookih^. 
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your process deals with it 


You without your process 

Right now things are looking pretty bleak, and without 
your process you would really be in trouble... 


The software doesn’t work, the codes 
a mess, and the CFO is going be mad 
as hell. I have no idea how to get 
things back on track... 


O 


o 
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the next iteration 


You with your process 

It’s not a perfect world. When your code — or someone else’s code you 
depend on — isn’t working, and your customer is breathing down your neck, 
it’s easy to panic or catch the next flight to a non-extradition country. But 
that’s when a good process can be your best friend. 



s 
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broken code happens 


BULLET POINTS - 

■ When you’re gearing up for the next iteration, 
always check back with the customer to make 
sure that the work you are planning is the work 
that they want done. 

■ You and your team’s velocity is recalculated at 
the end of every iteration. 

■ Let your customer reprioritize your user stories 

for a new iteration, based on the working days 
you’ve got available for that iteration. 

■ Whether you’re writing new code or reusing 
someone else s it’s all still just software and 
your process remains the same. 


■ Every piece of code in your software, whether it 
be your own code or a third party’s like Mercury 
Meals, should be represented by at least one user 
story. 

■ Never assume anything about code you are 
reusing. 

■ A great interface to a library of code is no 
guarantee that the code works. Trust nothing 
until you’ve seen it work for yourself. 

■ Code is written once but read (by others) 
many times. Treat your code as you would any 
other piece of work that you present to other 
people. It should be readable, reliable, and easy 
to understand. 



Dumb Quest! 


9ns 


Things seem to be in a really 
bad shape right now. What good is our 
process if we still end up in crappy 
situations like this? 

The problem here is that when you 
reused Mercury Meals' software, you 
and your team brought in code that was 
developed under a different process than 
yours, with an entirely different result- 
broken code. 

Not everyone developing software is going to 
test first, use version control and continuous 
integration, and track bugs. Sometimes, it's 
up to you to take software you didn’t develop 
and deal with it. 


So how common is this situation? 
Couldn’t I just always use my own code? 

Most software developed today is 
created on really tight timelines. You have 
to be productive and deliver great software 
quicker and quicker, and often with success, 
so the tempo rises as your customers 
demand even more. 

One of the best ways to save time in those 
situations is to reuse code—often code that 
your team didn’t write. So the better you get 
at development, the more reuse will be part 
of your normal routine. 

And when you start to reuse code, there's 
always that crucial time when you encounter 
code that simply does not work, and it’s 
easier to fix that code than to start over. But 
hold on...Chapter 11 is all about just how to 
do that, without abandoning your process. 


Dealing witk 

cocte tkat ctoesn’t 


work is part 
oi software 
ctevelopment! 

In Ckapter 11, 

you’ll see kow 


your process can 
lianctle tke keat. 
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the next iteration 



Software Developirient Cross 

Let’s put what you’ve learned to use and stretch out your 
left brain a bit! Good luck! 



Across 

2. If your software doesn't work, it's your.to get it fixed. 

6. If you.that a piece of code works you are heading for 

a world of pain. 

8. The.decides what is in or out for iteration 2. 

11. Your velocity helps you calculate how many.days 

you can handle in iteration 2. 

12.deals with the real world when you're planning your 

next iteration. 

13. Mercury Meals, other frameworks, code libraries and even 
code samples are all cases where you will want to 
consider.code. 

14.are also included in the candidate work for the next 

iteration. 


Down 

1 ■ Code.is one very useful technique to get you 

developing quickly and productively. 

3. Any work for the next iteration should appear on the. 

for the iteration. 

4. Trust.when it comes to reusing software. 

5. Never.any code you haven't written or run in some 

way. 

7. You should let your customer.your user stories, bug 

reports and other pieces of work before you begin planning 
iteration 2. 

9. You treat third party code the.as your own code. 

10. You may be following a great., but don't assume that 

anyone else is. 
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exercise solutions 



Software Development Cross Solution 
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Squashing bugs like a pro ♦ 



Your code, your responsibility...your bug, your reputation! 


When things get tough, it’s up to you to bring them back from the brink. Bugs, whether 
they’re in your code or just in code that your software uses, are a fact of life in software 
development. And, like everything else, the way you handle bugs should fit into the rest 
of your process. You’ll need to prepare your board, keep your customer in the loop, 
confidently estimate the work it will take to fix your bugs, and apply refactoring and 
prefactoring to fix and avoid bugs in the future. 


this is a new chapter 
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You with your process 


fffMIll 1 


[PltEWOCIiQDSlV 


It’s not a perfect world and when your code is not working and your customer 
is breathing down your neck it can feel like a perfect hell. Luckily your 
process has the unexpected, and the desperate, situation also baked right in. 
With your process, you have a plan... 



At the end of the last chapter, things were in a pretty bad way. 
You’d added Mercury Meals’ code into Orion’s Orbits and were 
all set to demo things to the CFO when you hit a problem. Well, 
actually three problems — and that adds up to one big mess... 


/o ⑽ system 

wheh you try ahd 

⑽ ii .i-t jus-t s-tops 
d— ahythihg. 


Your customer added three new user stories that relied on some 
new code from Mercury Meals. Everything looked good, the 
board was balanced and you completed the integration work 

when, BOO]V[!, you ran your code and absolutely nothing 
happened. The application just froze... 



You have a LOT of ugly new code 


When you dug into the Mercury Meals code, 
you found a ton of problems. What’s causing 
the problems in Orion’s Orbits, and where 
should you start looking? 


You have THREE user stories that rely on 
your code working. 

All of this would be bad enough, but there are three user 
stories that rely on the Mercury Meals code working, not 
just one. 

To make matters even worse, the GEO of Orion’s Orbits 
has talked you up to the CFO, and both are looking 
forward to seeing everything working, and soon... 
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bugs 


r^|^rpen your pencil 


Your software isn’t working, you’ve got code to fix, and the CEO of Orion’s 
Orbits is breathing down your neck, because the CFO is soon to be 
breathing down his. But how does any of this fit into your process? 


What would you do next? 



Wait! Tkink tkrougk wkat 

you would cto next and lill 
in tke blanks atove teiore 
turning tke page … 

/ tl^ Vou, boo, impatient develofev '… 

toM a jood 扣 

50 -to settlor. 
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always communicate 


First youVe got to talk to the customer 

Whenever something changes, talk it over with your team. If the impact 
is significant, in terms of functionality or schedule, then you’ve got to go 
back to the customer. And this is a big issue, so that means making a tough 
phone call... 


Great. Yeah, I'm gonna get screamed at, but 
ril tell the CFO were pushing things back. But 
I need a date...when will this be done? And 
doiVt tell me you don’t know, I pay you way too 
much to not know. 


O 


TV tus-bomc^s You v\ttA *to 

y 七 tWmy a pom-b y/iicv-c you 

make a estimate as 

-to lo^5 -bills mess y/ill take *to 

*bV^a*t estimate 
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bugs 


Standup meeting 


y'know, I wish I could just get my hands 
on one of those Mercury Meals developers; 
their code really sucks... 



Laura: Well, that’s why they were fired after the merger. It 
doesn’t really matter that they screwed up, though, it’s our 
code now... 

Bob: I know, I know. But poorly written code just burns me 
up. It makes us look like idiots. 

Mark: Look, can we move on? What do we do next? 

Laura: Well, we’re stuck with this code. So better start 
treating it like it’s ours. 

Mark: I think you might be on to something there... 

Laura: We already know how to deal with our own new 
code, if we treat Mercury Meals the same way, that should at 
least give us a good starting point. 

Bob: Ugh ...you mean we have to manage its configuration, 
build it, and test it, don’t you? Build scripts and GI all 
around? 

Mark: Yep, we’re going to have to maintain this stuff so the 
best first step would be to get all the Mercury Meals code 
into our code repository and building correctly before we can 
even start to fix the problem. 


It’s your code, so tke first 
step is to get it tuildingf... 
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prioritize what you do 



Broken Code Magnets 

Here are a bunch of things you could do to work your way through the 
Mercury Meals code. Put them in the order you think you should do them. 
Be careful, though, there might be some you don’t think will be worth doing 
at all. 


Figure 

S iS C ° de h:: n L d 

lm Pact rm 八 幼 01 If it h 

如、 Orbits^ 5 ^ 

- - code. 


Figure out how to package 
the compiled version to 
include in Orion r s Orbits 










sTaS^d 


etc 


一饮 二 eed W 


上 

t.Tae 




〜 tor y 


Create a place in your 
bug tracker for issues. 


Integrate the code into 
your CI configuration. 


Document the code 


File bugs for issues you find. 


Write a build script 


Run a coverage report to see 
how much code you need to fix. 


^ - the code and 


Do a security audit on the code. 


some 七 Wmy y\ccd *to 

be Aov\t wov-c 七 ha” ov\t^ 


_ ^^^^everse-engineer 

l ：： ir^Tcreate class diag^ 
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bugs 




亍免:. 
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bump some things for later 



Broken Code Magnets 

Here are a bunch of things you could do to work your way through the 
Mercury Meals code. Put them in the order you think you should do them. 
Be careful, though, there might be some you don’t think will be worth doing 
at all. 


To-Do List 

■ I •— ■ — 


This is a *tv-*idky 
oy>c. |*t ； s 
b> fop uf dll 
ovcv- ihe plate, 
so y/C f u 七 
•rt vcvtidally- 
*tvatk 
of as 
sooy> ds you 

-f md 

You mi^*t 
ded'ide ’rt 、 
r>o*t 

laicv-, bu 七 
-fov y\o^j) 
jus 七 v-cdovd 
cvcv-ytKmg you 
七 hmk dould be 
issue- 


Oy\tt it s ih the 
lrcposi-toiry, 七冰 h Vou 
Cl "tool loose oh 
This gets youv- 
⑽ t sci up. 



A^d r)OY/ wc cav\ s-tav-t 
thihkmg about gc-ttmg it -fco 
wo\rk. Well talk rwov-c about 
this *m B -few pd^es. 


—d ' —以广 

^ uv ^, UoS£ 

& 巧 f 一 

-to ^ 咖呼 atcv， 

you y/3ir\*b *to da^tuve 
*to build -tV^c so^*Uave. 

\y\ ov-dev- *to do ^foyA 
於 cd a Wild sdr»ft It's best 
•bo yt i\\t Codt ov-ja^iicd 
bc-wv-c you y/v-i*tc youv- 

so you Aov\{, V^avc *to 
y/v-*»*bc *i*t, ov-ja^izjc Code, 
and yoiAV shrift. 

；>ct Y ou *to *tV |S 

dc vc\rsioir\ toy\*bv"ollcd- By 

i 山 a»^Ws 
: W tw.s stc ? , you 
in<)vc *to deal sWWrl” 

|a\rouy>d code, youve alvcady 
c.owwi*b*tcd- 


, _ also make a s-tv-o^g ^ase -fov- 

puttmj *tiVis m youv v-cposi*bov-y be-Pove 
you shu-f-flc s*tu-fr dv^ouhd, so you v-oll 
thrnjs badk i-f you mess i*t up. 
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bugs 


So what about all the magnets we didn’t use? 
They’re not necessarily bad ideas, but here’s 
why we didn’t put them on our short list. 



This is bu*t v/c do 灼’七 knov/ y/ha*t 

wcVc jomj -fco have *bo make *to 七 he Code yet IVcVc jus*t 

y\o{, \rcady *to -fodus oy\ libvav-y vcv-sio^s. 





This is Jomg *bo be ir»\po\rta^*t otkCt *this CoAt is s*tablc, 
bu 七 until wc *tcs*tcd Bv\d v/ovk’mg, i*t’s 的。七 

mu 乙 h use y/ov-v-y'mg abou*t how *bo pa 乙 kaje up 

beyond *thc libv-av-y y/c alv-eddy have- 


A^o*thcv- impo\rta^*t emc, BY\d i*t almost jo*t B vcvti^al 
spo*t *to “Pile buy...’’. Bu 七 srndc v/cVc 竹 。七 mdk'rn^ 

*bo *tiic todt yc*b do^*t cve^ k^ov/ wha*t 
pavts well y\ttd } v/c decided *to leave "this o^c c^f-f o-f ou\r 
shov 七 we mi# 七 Con\t ba^k -fco i*t latcv. 

This oy\c jus*t da^*t happen ye*t. iVc do^*t have *tcs*ts, y/c 
do^*t khovz v/ha*t todt v/c ad*tually r\ttd } Bv\d v/e k^ow 
some o-f *thc todt is^*t y/ovk'mj. Tcs*t dovcv-ay a*t *this 
po'm*t wor/ 七 *tcll us mudh c^f value- 

This is oh-so-*tcw\ptm5 - l*t p\rovidcs d solid mc*tvid *bo 
oirrbo, y/hi 匕 h seems like d ^ood The pv-oblcrw 

wi*th *t^is is we do^*t know how c^f *thc 
Code well y\ttd) Bv\d v/e have absolutely y\o idea how 
mu 乙 h is rwissrn^. lVha*t i-f *thc\rc is d s*tubbcd-ou*t ^Idss 
where a whole sc^tio^ o-f -the libvav-y is supposed *bo be? 
Co^^c\r^s like -this make d mc-tv-id hcv-c useless. 

A 七 some pom 七 -this will be d jv-ca*t idea ； bu*t like some c^f 
|-thc o*thcv- -tasks, we do^*t khovz y/ha*t ^odc v/c ^eed yc*t ； 
d^d weVe about *to 50 anyway, so lets 

hold c^f-f o 灼 *this -fov ^ow. 

O-f all -the tasks we didn't choose *bo do, -this is *thc 
mos 七 likely 乙扣 dida*tc to ^c*t added ba 匕 k m. Bu 七 \rijh*t 
y\o^j, we do^*t khovz hov/ o-f libvavy y/c ^ccd- 
Lets yt a handle ov\ wha*t >/c have *bo use ； 仏⑶ well 
*bry d^d -fijuve ou*t how i*t’s supposed *bo v/ovk- 
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apply your process 


Priority one: get things buildable 


The code is in version control, you’ve written build scripts, and you’ve 
added continuous integration with GruiseGontrol. Mercury Meals is still a 
junky piece of nonworking code, but at least you should have a little bit of 
control over the code...and that’s your first priority. 


f\^ end'll by Y ou，r 

tohtmuous m-tcyatioh "tool 
Mcv-tuv-y Meals 

Wild 达 v-uh. 



BOO 


WrrcuryMis.k 卜 inb 训 

"ET - 〜 

jiwik ttfply fQFVinrtl 拖 n 【 


SuLwa pulMCwmcfl 』 M*rcur^MfialE. eulW 3ucc 财 Tul 
Oatt- 7 ZMT 1021.52 船 

la: PihNic: 


BUILD COMPLETE - MERCURY MEALS 

□ate of build ： 10H 3 IK 

Time Iq build: F5 fiefinndR 


fs/o cvv-ovs, v\o 

That’s a yod start. 




Now we can get 
started on those bugs. 


l on ：^~U : Kl: 

3 th 〜七 
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bugs 



Great, 

you re a real wunderkind; all 
that time and nothing works, still. Give 
that guy a promotion, huh? 


A little time now can save a LOT of time later. 

None of the original bugs are fixed just yet, but that’s OK. 
You’ve got a development environment set up, your code’s 
under version control, and you can easily write tests and run 
them automatically. In other words, you’ve just prevented all 
the problems you’ve seen over the last several hundred pages 
from sneaking up and biting you in the ass. 

You know that the code doesn’t work, but now that everything 
is dialed into your process, you’re ready to attack bugs in a 
sensible way. You’ve taken ownership of the Mercury Meals 
code, and anything you fix from here on out will stay fixed... 
saving you wasted time on the back end. 


Get tke code uncter source 
control and tuilcting 
successfully Lefore 
you change anytliing •“ 
inducting lixing tugs. 
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focus on functionality 


Wc could fix code. 


Now it’s time to figure out what needs to be fixed. At the end of 
Chapter 10 you took a look at the Mercury Meals code, and the 
prognosis was not good... 




AH o( these problems _ 

(o[ay\A, 5 hd this was ohly y/heh 
you peeked ih-to the -Pi\rst laycv- 
^ the /Wc\rduv-y /Weals Cod^ 


// Mercury Meals class conti 


// Follows the Singleton design pattern 
public class MercuryMeals 


丄丄 Wo \real dodurwCh-tatioh ov\ the dass, othev 

thah the (aci iuai \i tv-ics to —U 伙七 
the Smglc-toh … 

No*t mos-t dcsd\rip*tivc 
attribute ^dmes. 


public MercuryMeals^eallythang^^^ -- . _ _ 

〆 l/VW is *tKcv-c av\ Ov-dcv a*tVibu*tc? £vcr> a 

private Order cO; x ■ a ' 丄 IJ 

赦 e keywords U.e %1； 


privat 


select 



public MercuryMeals() 


Su\rdy this should be a does ^ 

make Ay sc^c as a-t-tv-ibu-tc Mme? 


V^avc av> dov>st\rutt>v 

dcdlavcd docs v>otWm 3 ? 


public static MercuryMeals getlnstance() 


^^lis.meallythang = new MercuryMeals 



return this.instance; 


oJ This dass is supposed h> be 
i^plcmch-tmg the smglcU patter, 
bu 七七 his looks like it ^caics a hew 

\y\siauc o-P /Wc^uvy/VIcals cvcvy -time 
七 his method is called... 


public Order createOrder 
return new Order ();} 


b y 

II C^dCp*tiohS 

l\OY\ 

a trained, a^d 

pass 七 he 

3s*t 


is III all 


77 TODO^eally should document this at some point ... TBD 

Meals c\^A as 

U ^ mde 山 s W 。 败如？ Uc. 


)n 


^|leas£ 

ohe 

is 


public MealOption getMealOption(String option) 

throws MercuryMealsConnectionException { 

if (MM.establish().isAnyOptionsForKey(option)) 

{ return MM .establish. getMealOption(option) . [0] }； 

ReWm^ulU a bad P ra^e. I Vs a bettev-idea Wa|se 

a 於 tV^at 3»vcs tall 饮 more Jo 仫破 k w ， 七 


return nu 
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bugs 


...but we weed to fix fuwctiowality 

But things might not be quite as bad as they look. You don’t have to fix 
all the bugs in Mercury Meals; you just have to fix the bugs that 
affect the functionality that you need. Don’t worry about the rest 
of the code — focus just on the functionality in your user stories. 



T\\tst avc uscv sWics 七 
七 he A1 cv"£.uv"Y to&t 

or\ly bo -(•»><* todc 
-tV^csc uscv- sW»cs defend or\. 


Functionality is 
tlie locus. Only 
lix code to lix 
user stories. 


(^^BULLET POINTS - 

■ Everything revolves around customer-oriented 
functionality. 

■ You write and fix code to satisfy user stories. 

■ You only fix what is broken, and you know what 
is broken because you have tests that fail. 

■ Tests are your safety net. You use tests to make 
sure you didn’t break anything and to know when 
you’ve fixed something. 


If there’s no test for a piece of functionality, then 
it’s the same as saying that functionality is broken 

While beautiful code is great, functional code 
trumps beautiful code every single time. This 
doesn’t mean to let things stay sloppy, but always 
keep in mind why you’re working on this code in 
the first place: for the customer. 
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test for bugs 


Figure out what fuwctiowality works 

You know that Orion’s Orbits was working fine until you integrated the 
Mercury Meals library, so let’s focus on that code. The first step is to 
find out what’s actually working, and that means tests. Remember, if it’s 
not testable, assume it’s broken. 


Mc\r^u\ryMcolls 
uses the smglctoh 
you 

^11 the 匕 

gctlhS-tolh^cO 
method -fco yt By\ 

i^s-tahde, instead 
o-P ihs-tolh-tiatmg 
the dass with the 
keywov-d- 


Wcvc s -tKc ihtcir-fa^ -to 

the /VJcals todt^ 



MerduryMeaU 


+ ytlnstanteO: M^rturyMeaU 
+ trcatcOv-dcv-O* Ov-dev 
+ submitOv-dev-fov-dev"* Ov-dev-)* boolean 

+ /VlcalOption 

+ 5ci0rdcv-sTKatA1aith^cY>/ov-ds(kcY>/ov-dis ： £ 卜叫 []): OrdtrD 


v>o*tc ： 

a dass '/ouv 


i’s 於 awea 


to 州 

I 0 US 7 

代 all”as a 於 a … 

develo?wcyvt s ^°?! 


You vc 七 buo 
bdsi^ 'm*tcv-fa^cs bo 
y/ovk alo% 
W\i\\ a^y i^clfcv 
todc *Bia 七 mi# 七 
be m *t^csc 
dlasscs. 



Order 

一 - ~ -— 

+ addMeal6)p*tioh(meal0p*tioh: /WealOp-tioh )： void 
+ add^cywo\rdfkcywo\rd ： void 


1 

RcwCW'kcV-, V/C 心七 
-bo use i\\t 

y\urwkcv* 3 S 七 he 
Vt^oyd -fov" 3 meal. 
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Your job is to create a unit test that exercises all of the functionality your user 
stories need. The “Order Regular Meal” test creates an order, adds a regular meal 
option to it (in this case, “Fish and chips”)，and then submits the order to Mercury 
Meals. Using the class diagrams on the lefthand page, write the code for this test 
of the “Order Regular Meal” user story in the spaces provided below. 


package test.com.orionsorbits.mercurymeals; 
import com.orionsorbits.mercurymeals•*; 
import org.junit.^; 


public class TestMercuryMeals { 
String[] options; 

String flightNo; 


@Before 

public void setup () 


This should be a valid ^ ca \ op £ ioh 



TV usev sto^ *tW»s 
itsi lotuses oy^. 


options = {"Fish and chips"); 


flightNo = "VSO1 n ; 




T\\t dodc (or 


@After 

public void tearDown() 
options = null; 
flightNo = null; 


sc*tUpO ar\d 

'tcav'Po^O avc 



alvcady m pladi 


c. 


@Test 

public void testOrderRegularMeal() 



TKvoy/ a Mcal0f*t'io^No*tPour>di6%dCftio^ 
i-f meal is^*t (o\ay\A, By\A 
Ovdcv-No*tA^^P*tcdE^cf*tio^ i-f 
ov-dev ta^*t be subm’rbted. 


throws MealOptionNotFoundException, OrderNotAcceptedException { 


MercuryMeals mercuryMeals = MercuryMeals.getlnstance(); 



You y\ttA 


move—ov 
-fc>wcv—ImCS *to 
implement youv 
solution -- 七 his 
is y/iiat >*t *took 


*to yt 

*tcsi y/ 


ouv 
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think about estimating 



Your job was to create a unit test that exercises all of the functionality your 
user stories need. The “Order Regular Meal” test creates an order, adds a 
regular meal option to it (in this case, “Fish and chips"), and then submits 
the order to Mercury Meals. 


package test.com.orionsorbits.mercurymeals; 
import com.orionsorbits.mercurymeals•*; 
import org.junit.^; 


public class TestMercuryMeals { 
String[] options; 

String flightNo; 




@Before 

public void setup() { 

options = {"Fish and chips"); 
flightNo = ’ ▼VS01 n ; 


rtcvVs 从 C USCV 
s ^v>y its 

/\/lcv , 6uv'y 


@After 

public void tearDown() { 

options = null; 
flightNo = null; 


@Test 

public void testOrderRegularMeal() 

throws MealOptionNotFoundException, OrderNotAcceptedException { 


七 hou 分 you 
don’ 七 

c%a^*bly - 
\\o^i 七 iVis 

Codt v^rks, 
•rb should 

be tlcav 
y/iia 七 i 七 

should do 



MercuryMeals mercuryMeals = MercuryMeals•getlnstance(); 

Order order 5 mercuryMeals.createOrderO; r 

MealOptioh mealOptiow 5 mercuryMeals.getMealOptiohtoptiowstOl); A 
if (mealOption hull) < 々 / H 丄 

^order:addMealOptioh(mealOptioh); - up pL 

> else< bci cs 



throw hew MealOptiohNotFouhdExceptioh(mealOptioh); 


*11^9 V-Uh. 


orderaddKeyword(flightNo); 
if (!mercuryMeals.submitOrder(order)K 
throw hew OrderNotAcceptedExceptiow(order); 

> T 

These av-c just ways 

■to 匕 ause "the tcs-t -to tdil ； av\d 
say something *m the Alcv-^uvy 



Add 七 he w f*isV> by\A meal 
o^*biof\ "to ovdev'^ *tic 
ovdiev- *to 七 he rtumbev-, 

ar\d 从⑼ submit ovdev- *to 

Meals. 


Aleals API didn't wo\rk. 
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vurt 

NOW you know whafs^working 


a，UaW 咖 W. 



No C\r\ro\rs ov- Wol\rh'm^s 

wc\rc iv-iggcv-cd... 


• bu*t a lo*t o( *tKc 
•tcsis art 



Laura: Right, about 30% of the code we need to 
use is failing our tests. 

Mark: But that doesn’t tell us anything about how 
much work it will take to fix thing. And it’s 30% of 
the code that’s written...how much of that do we 
need? 

Bob: And there could be whole chunks of code 
completely missing, too. I don’t know how much 
new code we’re going to have to write. 

Mark: How do we estimate this? 

Bob: There has to be a better way to come up 
with an estimate besides just guessing, right? 


What would you do? 
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spike tests 


Spike test to estimate 

30% of the tests you wrote are failing, but you really have no idea if a 
single line of code would fix most of that, or if even passing one more 
test could take new classes and hundreds of lines of code. There’s no 
way to know how big a problem those 13 test failures really represent. 

So what if we take a little time to work on the code, see what we can get 
done, and then extrapolate out from that? 

This is called spike testing: you’re doing one burst of activity, seeing 
what you get done, and using that to estimate how much time it will take 
to get everything else done. 

Take a week to conduct your spike test 

Get the customer to give you five working days to work on 
your problem. That’s not a ton of time, and at the end, you 
should be able to supply a reasonable estimate. 




Look, my patience is wearing thin. You 
better have a solid estimate at the end 
of this week, or were going to have a 
real serious talk, OK? 




w adc -吖 cst^atc. 


"the duS'(jomc\r ^ives Kis 
0^, you blodk out 3 week 
■to do you\T Spike tes-tihg. — 
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Pick a random sampling from the tests that are failing 

Take a random sample of the tests that are failing, and try to fix just those 
tests. But be sure it’s random — don’t pick just the easy tests to fix, or the really 
hard ones. You want to get a real idea of the work to get things going again. 


S !f ouVc ㈣ 叫 a 

P^ess, eve, ih spikc 七 



OK, well work on a bug each. 

Let*s just draw bugs out of a hat, and 
see if we can knock one out as quickly 
as possible. Then, on to the next bug... 


Use ^ V>^ 七秦 

㈣ F 

铋柄 — w 亇 

• m -to WOVAV 

At Jo^ P USS . 



At the end of the week, calculate your bug fix rate 

Look at how fast you and your team are knocking off bugs, and come up with 
a more confident estimate for how long you think it will take to fix all the bugs, 
based on your current fix rate. 




To-tal bugs you\r 
Cir\*biV"C ■tcaw' 


Numbcv- c4 - days ’m 
"the spike -tes-t 


Your daily 
bu^ -Piy. va-te 


l Bujs likely -to be fev- day, 

*tV^is v3*tc s*b3ys s*tc3dy 
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estimate whafs left 


What do the spike test results tell you? 

Your tests gave you an idea as to how much of your code was failing. 
With the results of your spike test, you should have an idea about how 
long it will take to fix the remaining bugs. 

number bujs durmj 

i\xt y/cck-lo^j sfikc itsi 

4/5 二 

丁 he humbev- wo^k 

days ih the spike icsi 




bu^s 


fev day 

V y o uV- -tcam^S buj -f'»% V-a*tc 

Ns ^" (or spike test 


You caw then figure out how long it will take for your 
team to fix all the bugs 


V x 
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The bugs \c^i, you -fixed 

so 州 c oh the spike test. 



Hov/ lo% i*t would *takc youv* v/Kolc 
七 cam *to f ix all 七 he vcma'm'rn^ bu^s 


So we fixed some bugs AND we 
now know how long it will take for the 
entire team to fix all the problems. But 
rm still not feeling very confident... 


0 
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Hmm, are you sure a team will always 
squash bugs like they did in the spike 
test? How can you have any confidence 
that you'll fix all the bugs in seven 


When it comes to bug fixing, we really 
can 9 t be sure 

When it comes down to it, a spike test really only gives 
you a more accurate estimate than a pure guess. It’s not 
100% accurate, and may not even be close. 

But the spike test does give you quantitative data upon 
which you can base your estimates. You know how many 
bugs you fixed, and it was a random sample, so you can 
say with a certain degree of confidence that you should 
be able to fix the same number of further bugs in roughly 
the same amount of time. 

However, a spike test does not give you any qualitative 
data. This means that we really only know how fast 
you can fix the bugs that we just worked on. We don’t 
really know how bad things might be in stuff waiting 
to be fixed. There’s still the potential for a bug to be 
in Mercury Meals that will blow your estimate out of 
the water, and unfortunately, that’s a fact of life when it 
comes to bug fixing, especially on third-party software. 
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factor in confidence 


Your team's gut feeling matters 

One quick way that you can add some qualitative feedback into your bug fix estimate is 
by factoring in the confidence of your team. During the spike test week, you’ve all have 
seen the Mercury Meals code, probably in some depth, so now’s the time to run your fix 
rate past your team to factor in their confidence in that number. 



Feed confidence into your estimate 

Take the average of your team’s confidence, in this case 70%, and factor 
that into your estimate to give you some wiggle room: 


( 0.0 >< 






10 % 


丁 csWatcW 


- 10 days ^ 

七 o {ht remaihihj bugs 
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Dumb Questions 


How many people should be 
involved in a spike test? 

Ideally you’d get everyone that you 
think will be involved in the actual bug fixing 
involved in the spike test. This means that 
you not only get a more accurate estimate, 
because the actual people who will finish off 
the bug fixing will be involved in the future 
estimated fixing task, but those individuals 
also have a week to get familiar with the 
code. 

This especially helps when you ask those 
members of your team to assess their 
confidence in the estimate that comes out 
of your spike test. They'll have seen the 
code base and have a feel for how big all 
the problems might have been, so their gut 
feeling is worth that much more. 

How do I pick the right tests to 
be part of the spike testing when I have 
thousands of tests failing?! 

Try to pick a random sampling, but 
with an eye towards getting a selection of 
bugs that vary in difficulty. So what you’re 
looking for first is a random sample, but 
then you want to make sure that you have 
a cross-section of bugs that, at a glance, at 
least appear to be challenging and not just 
the easiest things to fix. 

I thought in test-driven 
development, we fixed each test as we 
came across it. Are we not using TDD 
anymore? 

This is still TDD, for sure. But this is 
about existing code, not writing tests for 
new code. You don’t want to stop and try to 
fix each test just yet. We need a big picture 
view of the code right now. 


However, this does cause a problem if you’re 
using Cl, and your build fails when a test 
fails. In that case, after you get a count of 
failing tests it might make sense to cheat a 
little and comment out the failing tests. Then 
add them back in one at a time. This is risky, 
and might get you on the TDD Most Wanted 
list in no time flat, but practically speaking 
you might want to consider it. The most 
important thing is you get all of those tests 
passing, and nothing’s left commented out. 

Why did we add in that confidence 
factor again? 

Factoring in confidence gives you 
that qualitative input into your estimates 
where your team gets a chance to say 
how difficult they feel the rest of the bugs 
may be to fix. You can take this pretty far, 
by playing planning poker with your bugs, 
but remember that the longer you spend 
assessing confidence, the less time you 
have to actually fix the bugs. 

It’s always a compromise between getting 
an absolute estimate for how long it will 
take to fix the bugs (and this can really only 
be obtained by actually fixing them all) and 
getting a good enough feel for how fast you 
can squash bugs and getting that estimate to 
your customer. 

Why five days for a spike test? 

Good question. Five days is a good 
length because it focuses your team on 
just the spike test for a week (rather than 
attempting to multitask during that week), 
and it gives everyone enough time to do 
some serious bug fixing. 

Can I use a shorter length? 


You can, but this will affect how many 
bugs your team can work through, and that 
affects your confidence in your final estimate. 
In the worst case scenario, no bugs at all 
are fixed in your spike test, and you’re left 
confused and without a real end in sight. 

Five days is enough time for some serious 
bugs to be fixed and for you to be able 
to come out of the spike test with some 
confidence in your estimate for fixing the 
remainder of the bugs. And in the best case 
scenario, you come out of the spike test 
week with no bugs at all! 

So should I do this on code we’ve 
developed, too? 

You really shouldn’t need to. First of all, 
you shouldn’t have a massive stack of failing 
tests. If a test is failing, the build should be 
failing, and you should fix things immediately. 
And with bugs, they should be prioritized in 
with your other work, so it’s unlikely you’ll 
suddenly get a giant stack of bugs you need 
to sort through. And finally, you and your 
team should know your code base pretty 
well. Your coverage reports provide value, 
and you know there can’t be too much code 
involved in any given bug. 

How can I be absolutely sure that, 
even when I’ve factored in my team’s 
confidence, that 10 days is definitely 
enough to fix all these bugs? 

You can’t. Ten days is still just an 
estimate, and so it’s how long you think it 
will take, based on your spike test and your 
team’s gut feelings. You’ve done everything 
you can to be confident in your estimate, but 
it is still just an estimate. When it comes to 
bugs, you need to be aware that there is a 
risk that your estimates will be wrong, and 
that’s a message that you need to convey to 
your customer too... 
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always communicate 


ftive your customer the bug fix estimate 

You’ve got an estimate you can be reasonably confident in, so head back 
to the customer. Tell him how long it will take to fix the bugs in the 
Mercury Meals code, and see if you can get fixing. 


So youve spent 5 days fixing bugs, and \Ys going to 
take another 10 days to fix the bugs. Not good, but at 
least ifs progress, I guess. The demo for the CFO takes 
precedence here, so I’ll bump two user stories to the 
next iteration to make room for these fixes. 
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Back to the magnets we didn’t use on page 391 ■ Would you do any of these activities now? 
Why? Any others you might add that aren’t on this list? 



Figure out how to package 
the compiled version to 
include in Orion's Orbits. 



Would you do this now? Why? 


Would you do this now? Why? 


Would you do this now? Why? 



Would you do this now? Why? 



Would you do this now? Why? 



Would you do this now? Why? 



Would you do this now? Why? 
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apply other techniques 


Back to the magnets we didn’t use on page 391. Would you do any of these activities now? 

Why? Any others you might add that aren't on this list? 

BteftctSe 

§OLyiiOH 

Would you do this now? Why? .^Ipiybc-. .(^s possible 
七 .some o-f library is behind py\t, o( ou\r 

bu^s. YouVc. .七 9. .y)ccd. io "tKi?. pui/bq ^ei . 

cvcv-y-thmg wov-k'mj by c^d o-f -the i*tcv-a*tio^ anyway. 




Would you do this now? Why? .0.»|y. ^uv-Jrc^i 

app.vrocidK .•⑸ ^ 土 .joi^.-bo .du*t. .it.. .TKis. is. basically 
vtfAt+dVriy^ 石 t Jcvcl -. 2^ct .workiyij. 

扣 d .you should, .pvpbilbly skip, ^is ； . 

Would you do this now? Why? .AbjoJuitlyi. Every... 
ftlc. .yojA .$t\QvJd .cp.mc.PMt .<?^ .y.Q^v. .dca»vip .With .clcav ： 

doC.u 畎 cntation.. At A .mijoinMnw* .explain .the. C.odc. you. ye. 

"toudhccl y/hi|c. a buj.. 



Would you do this now? Why? .Probably ： .Y<?ia. 乃魏. 

.have. a set.p^.tests.ibat.s^ppie; })qm tKc sys£c.^.. 
yo 认 yittd：. T.hU .will • gi.v.c. yovi. idea, .of. Kov/ •畎 v^b. • : the •. 

ov c\ra)l to At base you actually use ； whidh is ausc-ful .^ebri^- 



Would you do this now? Why? y'.pt .. 

i^wb.ly.usc-fuj. Who (敗 hoyj. bij.^i. to4c. .b 办 c j?j 

c^Cc^i .ip. hw. ii rdaics .*to. .ihc. 妫汕切 .ypu. need 

ip. .3? . 七 . ^<>rki^? 




Would you do this now? Why? 如' ./W/. Apde. ib^i. 

yb. .ipudKcd. .miK .you\r. : U?:U .sKpuld b.c. 乂 h 技 kd fcr. 

scA^riiy. i 衿撕 ' •[•?. .you. .ca>>. • 扣 y .pr.pb.k 咐 . 杜押>土 W. … 

youv- test *to pass, jo -for it ^o*t, daptu\rc i 女 

办 .A .ii. . 

Would you do this now? Why? tc 77 -.it .depends 
oy\ how the dodc |s ;> J4; youVe havm^ -ty-oublc 

-fjjuy-i^.j.oui. .y/.h^i.a blo£.k c4 - todc is .ip. 4o>. ;thi. s . •.. 

hejp. y/g\A .yt. youv；. hedd. d\rou»>d .ii ： . 
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Dumb Quest? 


9ns 


I noticed that the bug fixing tasks on page 406 both had 
estimates. Where did those estimates come from? 

Good catch! Bug fixing tasks are just like any other type of task; 
they need an estimate, and there are a number of ways that you can 
come up with that. 

You can derive the estimate, dividing the total amount of days you’ve 
calculated evenly by the number of bugs to fix, or you can play 
planning poker with your team. Whichever approach you take, your 
total planned tasks for bug fixes must never be greater than the 
number of days calculated from your spike test. 

When fixing bugs, how much time should I spend on 
cleaning up other problems I notice, or just generally cleaning 
up the code? 

This is a tough call. It would be great to fix every bug or 
problem you see, but then you’ll likely finish all your tasks late or, 
worse, end up refactoring your code indefinitely. 

The best guideline is to get the code into a working, pretty decent 
state, within the time allotted for your bug fixing task, and then move 
on to the next task. First priority is to get the code working; second 
is to make it as easily readable and understandable as possible so 
that bugs are not accidentally introduced in the future. If there are 
problems you found but couldn't get to, file them as new bugs and 
prioritize them into a later iteration. 


Q/ What did that five-day spike test period do to our iteration 
length? 


Right now, we're getting ready for the next iteration so we're 
between iterations. If there’s a master schedule, the five days needs 
to be accounted for there, but in terms of iteration time, it's basically 
off the clock. After you get your board sorted out and everything 
approved by the customer, though, you should kick off a normal 
iteration. If you’re forced to do a spike test in the middle of an 
iteration, that’s a case where it’s probably OK to slip the iteration end 
date by a week, assuming nearly everyone is participating. 


If only a small number of developers are participating in the spike test 
and everyone else is continuing the iteration, you probably want to 
drop that five days’ worth of other work from the iteration, but still end 


on time. 




C^: You said try and get code into a “pretty decent” state. 

What does that really mean? 

This is really a judgment call, and in fact this is where you 
get into the aesthetics of code, which is a whole book on its own. 
However there are some rules of thumb that can help you decide 
when your code is good enough and you can move on. 

First, the code must work according to your tests. Those tests 
must exercise your code thoroughly, and you should feel very 
confident that the code works as it should. 

Secondly, your code should be readable. Do you have cryptic 
variable names? Do the lines of code read like Sanskrit? Are you 
using too much complicated syntax just because you can? These 
are all huge warning signs that your code needs to be improved in 
readability. 

And finally, you should be proud of your code. When your code is 
correct and easily readable by another developer, then you’ve really 
done your job. It doesn’t have to be perfect, but “pretty decent” starts 
with your code doing what it should and ends with it being readable. 

This sounds like the same approach as the perfect-versus- 
good-enough design stuff we talked about earlier, right? 

Yes, it’s based on exactly the same principle. Just as you can 
spend hours improving a design, trying to reach perfection, you can 
waste exactly the same time in your coding. Don’t fall into the trap 
of perfection. If you achieve it, then that’s great, but what you’re 
aiming for is code that does what it should, and that can be read and 
understood by others. Do that, and you’re coding like a pro. 


Beautiful cocte is nice, 
t>ut testect anct reactatile 
cocte is cteliverect on time. 
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successful deliveries matter 


Things are looking good 


tt § 


So you’ve picked off all the bugs from Orion’s Orbits, and 
all functionality is working according to the results of your 
continuous integration build process... 


Vour Cl boo\ »S 

Guilds 

passes »*b *tcs*b- 


^ nn 


㈣ 


[CrLfi^CDnlfrul]. McrLmvMHlsr Suikf 5ut«s^ful — Inbox 

■ 砸 〆 V ^-T - ! vO J 

物 Hec^VAJ! fmwjrd Pr^ "n»DD 



From: nuiaanMhix 
Su^rTct; [CrulisCflSTlrBfl^ M«rEUFyW4*ia Bul4 SiKEgaidul 

Dki «： 7 SOpJ IflSI €UJ 

To. Dan Prion 


BUJLD COMPLETE - MERCUR¥MEALS 

Date Erf build: "B7M 1iWM7 ICJ ap If ； 

TlmctD bUUd: Cl hwjixk±{ 

Lao4 chzufegcd: OZMIfiW? m t；E M 

iDbon 


Laal lev 為 dAxl docunicnlr 


Erpofo/Wamlnga ： id) 


to MctTftJrv ATI 



\4o cv-v-ov-s... 


Unit Tenia 


All PD4 


I.. .and all -the tests av-c passmg/ 


File Edit Window Help Spike! 


hfsd> java -cp junit.jar;. org.junit.runner.JUnitCore 

test.com.orionsoribits.mercurymeals.TestMercuryMeals 

JUnit version 4.3.1 


Time : 75.999 
OK (36 tests) 


hfsd> 


\ 


TV output -fv-om 

hCw /V|c\rduV"y 
Aleals -fuhttioh^l'rty 


㈣ 2爲 
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t ft 


and you finish the iteration successfully! 


You’ve reached the end of this iteration and, by managing the work 
and keeping the customer involved, you’ve successfully overcome the 
Mercury Meals bug nightmare. Most importantly, you’ve developed 
what your customer needed. 





L. bu 七 v/’rth fviov’rtiz^ti 。 灼 
of >wov*k >wi*th 七 he 
dusiomcv- ar>d >wi*th 
cvcv-vo^c s^uashm^ bu^s, 
you -rmished oy\ 七 ime. 


y/o usev sW»C s Y/CyrC 
kum^cd bu*t avc ^ 
stro% da^a»da*bcs +ov 
i\st vb^ratuw. 
W*t ⑽七 


JO 


V^u ^ornplctcd iw 
usc\r slopes av\d tasks 
^ihdludih^ "theiv bu^ -pix 
tasks) ih this itev-atioh. 
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functionality wins 

州<«七 impoirtah-tly 

AN_tie customer is happy 

You and your team of developers, by applying your best practices and 
professional process, have overcome the perils of integrating third-party code, 
fixed the bugs that arose from that integration, and have delivered the demo 
on time. The CFO, who just cares that things work, is pretty stoked. 



©JPlaftS 


icescfv 时 to 艏 


3rc by 




You got the Mercury Meals integration working!? 
That^ fantastic, guys; you really deliver! You II all be 
featured in my review to the board—better start 
ordering those PlayStation 3*5 now! 


Tk all -心 •心 

七 Mcv-duv-7 Meals 


TV,c (W 、 0^ ⑽.， 

^ _ 孙讪 o s，s 70UV 
? a7d^c6ks (a^d amoves ^a.scs； 
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S ^iy issues i. 

:㈣ 碱 


But wait a sec, isiVt there a lot of code in Mercury's Meals 
that we haven’t tested? We've only proven the parts of the 
Mercury Meals code that are used by our user stories, but 
doesn’t that mean you re shipping software that could contain 
a stack of buggy code? That can’t be right, can it? 


You’ve uncovered an unfortunate truth. 

Yes, there may be bugs in the code, particularly in 
the Mercury Meals code that you inherited. But you 

delivered code that worked. 

Yes, there are potentially large pieces of that library that 
haven’t yet been covered by tests. But you have tested 
all the code that you actually use to complete your 
user stories. 

The bottom line is that pretty much all software has some bugs. 
However, by applying your process you can avoid those bugs 
rearing their ugly head in your software’s functionality. 

Remember, your code doesn’t have to be perfect, and often 
good enough is exactly that: good enough. But as long as 
any problems in the code don’t result in bugs (or software 
bloat), and you deliver the functionality that your customer 
needs, then you’ll be a success, and get paid, every time. 


Real success is about DELIVERING 

FUNCTIOMLITY, period 
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Tools for your Software Pevelopment Toolbox 


Software Development is all about developing 
and delivering great software. In this chapter, 
you learned how to debug like a pro. For a 
complete list of tools in the book, see Appendix ii. 




BULLET POINTS 


BeW you 6— a ^ 

make sure \i is do^rollcd a^d W“daWc 

b—Uode ^ 

s ? *,kc test ^ estimate lo^ «*t take 

■to f 1% {\\tm 

FatW *rn your team 、 co^\AtUt ^ 

Use tests to 


^ 5 ^ sor ^e 
the key 

tc^hhi^ucs you 

m -this 
匕 —tar … 

...a^d so^C ^ 
从 osc tctW^cs. 


Developrhe^ PH^jples 

〜 hohest with youv “sWn cspcdially 
wheh *thc hews is bad 

tVo\rkihg so^twave is y ou \r — phovity 

Readable ahd uhdevsbhdable 仏 de domes a 

^lOSC SCCoy\d 

W you haWt tested a piede todc, 
Assume "that i*t docsh ； *t wov*k 

Fix -Puh^tiohalrty 

Be pvoud youv dode 

All -the dodc ih you\r s<yfiy/a\re, ever) ihc 
W you did^i wvitc ; *, s y OU v vcspohsibility 


■ Before you change a 
single line of code, take 
ownership of it by adding it 
into your build process and 
putting it under source code 
management. 

■ Take responsibility for all 

the code in your software. 

If you see a problem, then 
don’t cry “it’s someone else’s 
code”; write a test, then fix 

it. 

■ Don’t assume a single line 
of code works until there is 
a test that proves it. 

■ Working software comes 
first; beautiful code is 

second. 

■ Use the pride test. If you’d 
be happy for someone else 
to read your code and rely 
on your software, then it’s 
probably in good shape. 
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BugSquashingCross 

Flex your brain with this crossword puzzle. All of the words below are 
somewhere in this chapter. 



Across 

2. At the end of a spike test you have a good idea what your 
team's.is 

4. When you apply your refactoring experience to avoid 
problems up front, that is called .... 

9. When new bug fix tasks appear on your board, your 
customer might need to re-.... the work left in the current 
iteration. 

10. When fixing bugs you are fixing .... 

11. Fixing bugs becomes .... or sometimes full stories on your 
board. 

12. A spike test should be around a .... in duration. 

14. Close second priority is for your code to be .... and 
understandable by other developers 

15. You should always be .... with your customer 

16. The first step when dealing with a new chunk of unfamiliar 
code is to get it under source code .... 

17. Before you change anything, get all your code .... 


Down 

1. Take .... for all the code in your software, not just the bits 
that you wrote 

3. The best spike tests include attempting to fix a.of the 

bugs. 

5. You should be .... of your software. 

6. When you change code to make it work or just to tidy it up, 
this is called.... 

7. You can account for your team's gut feeling about a 
collection of bugs by factoring in their.... in your big fixing 
estimate. 

8. To help you estimate how long it will take to fix a collection 

of bugs in software you are unfamiliar with, use a. 

13. Top priority is for your code to .... 
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12 the red World 






Having a process in life 



You’ve learned a lot about software development. But before you 

go pinning burn-down graphs in everyone’s office, there’s just a little more you need to 
know about dealing with each project — on its own terms. There are a lot of similarities 
and best practices you should carry from project to project, but there are unique things 
everywhere you go, and you need to be ready for them. It’s time to look at how to apply 
what you’ve learned to your particular project, and where to go next for more learning 


this is a new chapter 


software process defined 


Pinning down a software development process 

You’ve read a lot of pages about software development process, but we haven’t 
pinned down exactly what that term really means. 


. 

A software development process 

V # is a structure imposed on the 

development of a software product. 






心 n〆. 




Notice that definition doesn’t say “a software development process is four-week 
iterations with requirements written on index cards from a user-focused point 
of view...’ software development process is a framework that 
should enable you to make quality software. 


There is wo silver-bullet process 

There’s no single process that magically makes software development succeed. 
A good software process is one that lets your development team be successful. 
However, there are some common traits among processes that work: 


Develop iteratively. Project after project and process after process 
have shown that big-bang deliveries and waterfall processes are 
extremely risky and prone to failure. Whatever process you settle on, 
make sure it involves developing in iterations. 

Always evaluate and assess. No process is going to be perfect 
from day one. Even if your process is really, really good, your project 
will change as you work on it. People will be promoted or quit, new 
developers will join the team, requirements will change. Be sure to 
incorporate some way of evaluating how well your process is working, 
and be willing to change parts of the process where it makes sense. 

Incorporate best practices. Don’t do something just because it’s 
trendy, but don’t avoid something because it’s trendy either. Most of the 
things that people takes for granted as good software development started 
out as a goofy idea at some point. Be critical — but fair — about other 
processes’ approaches to problems, and incorporate those approaches 
when they might help your project. Some people call this process 
skepticism. 


A great 

software 
process is a 
process tkat 

lets YOUR 


ctevelopment 
team te 
successluL 
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the real world 


A good process delivers good software 

Let’s say your team loves its process. But suppose your team has yet to deliver a project 
on time, or deliver software that’s working correctly. If that’s the case, you may have 
a process problem. The ultimate measure of a process is how good the software is 
that the process produces. So you and your team might need to change a few things 
around. 


Before you go changing things, you need to be careful — there are lots of wrong ways to 
change things. Here are a few rules to think about if you’re considering changing part 
(or even all) of your process: 



Unless someone is on fire, don't change things mid-iteration. 

Changes are usually disruptive to a project, no matter how well-planned they are. 
It’s up to you to minimize disruptions to other developers. Iterations give you 
a very natural breaking point. And good iterations are short, so if you need to 
change your process, wait until the end of your current iteration. 



Develop metrics to determine if your changes are helping. 

If you’re going to change something, you’d better have a good reason. And you 
should also have a way to measure whether or not your change worked. This 
means every change is examined at least twice: first, to decide to make the 
change, and then again — at least an iteration later — to measure if the change 
was a good idea or not. Try to avoid touchy-feely measures of success, too. Look 
at things like test coverage, bug counts, velocity, standup meeting durations. If 
you’re getting better numbers and better results, you’ve made a good change. 

If not, wait for the next iteration, and be willing to change again. 



Value the other members of your team. 

The single biggest determinant of success or failure on a project are the people 
on your team. No process can overcome bad people, but good people can 
sometimes overcome a bad process. Respect your fellow team members — and 
their opinions — when evaluating your process and any changes you might want 
to make. This doesn’t necessarily mean you have to run everything by committee, 
but it does mean you should try and build consensus whenever possible. 





If you could change one thing about your current software process, 
what would it be? Why? How would you measure whether or not your 
change was effective? 
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evaluate everything 




Below are some of the best practices you’ve learned about in earlier chapters. For each 
technique, write down what you think it offers to a software process, and then how you could 
measure whether or not that technique helped your project. 


What does this technique offer? 


How do you know if it worked? 

The big board 







What does this technique offer? 


How do you know if it worked? 


User stories 



What does this technique offer? 


Version control 


How do you know if it worked? 
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the real world 


What does this technique offer? 


How do you know if it worked? 


Continuous integration (Cl) 



Test-driven development 
(TDD) 




Test coverage 


you are here ► 


421 






































ensure changes improve things 



Below are some of the best practices you’ve learned about in earlier chapters. For each 
technique, you were asked to write down what you think each technique offers, and then how 
you could measure whether or not that technique helped your project. 



The big board 


What does this technique offer? . . 

y/hcy-c they y/ha*t else to be doy\c, a^dl what has -to 
m -this you also see i-f youVc schedule- 

How do you know if it worked? .. should be -fcwc\r bujs. 

-fy*ow\ missed ^catu)rcs, bc*ttc\r of u^pla^^cd 

by\A idea o-f duy-i^g this i*tc\ra*tio ^； 


= -… 1 What does this technique offer? ..A way.io. splii uf. so^iway：?... 

一 t ^ "一 J • • y-c^ujircmc^is ； ay\d make. sure, -the 

— I )?. A^f.iu'rcd do\r\rcdtly-. 

How do you know if it worked? . .fewey*. 

•— 和中 . 呼 .• 斗 5 ? 也化 *? 冰 ? 丄七 y.. !/?!?(• • 七 y 

User stories should also 50 up, smdc dcycl opc\rs k^ow wha*t *to build bcttcy -； 




u 


Version control 


What does this technique offer? ..Cb^jcs tav\ be disiy-ibuied..... 
a£.\ross a tca»v\ y/ithout y*iskmj J；ilc loss dr^d ovcy*yyy-i£cs ; you dd^ 

ajso a^d b\ra^h a^d.kc^P.^P. .—iK 

How do you know if it worked? ... Ko dodc ovey-wy-iic^ CoAt 
lost ^\rom bad mey-jes^ d)r)d dMhjes joo pv\t pa\r*t o( so^^y/ay-c 
should^t a-f-fedi. o-thev ； picdcs dv}d dduse Jx> lorcak ； 
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the real world 



Continuous integration (Cl) 


What does this technique offer? .T_h?...... 

because Compilation. Bjr}d arc pay-t. o( dhedk-m, a^d.thc 

dodc \y\ /the y;cposi*b>\ry alvyays works. 

How do you know if it worked? ..|N/obp(ly.dbcAb. oui to^, • 扣 .d.... 

• .-f]mc}s ou-jb 丄七 . docsK)^ y/p\rkj o\r. doesn't Compile... y ： Cpp\ris. 

.should .50. dov/^ smdc todc mus-j ； pass . 七 0 七 ?.: t?. fee. Ab.c^kcd jrv.... 



Test-driven development 
(TDD) 


What does this technique offer? .. .-to c^suyc .you\r. todt 
is/tcs-jt^blc -f\rom the yc)ry o( deydopme^t. fiiUo 

mty-pdludcs .*tcst r: -f\ric^dly f3*t*tcv；^s your todc ： 

How do you know if it worked? ..Pcwc^.bujs because -tes-tmj 
sta\r*b cay-licy；. Bc-ttev ； ^oycy；a jc, a^d every l*mc o( to At 
ma*ticy-s ; PossilDfly bc*ttc\r dcsi^, aY\d less legacy dodc- 



Test coverage 


What does this technique offer? . Bciicr ,^tiy；\ts o»>. ..... 

Code is bemg -tcs-tcd a«rvd used-^ .^.y. fe>. .bu^s because -they 
usually cy.ist.i>).u^*tcs*tcd[ a^d uD^oycycd ,toAt : 

How do you know if it worked? ... Bugs b^omes ^used oy\ . 
dascs because the ma*m par-ts of dodjc a\rc we 11--tested ； .Less 
unused ov U dv-u-f"t w todt •bhats u^dovcv-cd 灼 o*t usc-ful. 
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formalize if necessary 


Formal attire required. 


There are projects where you may need more formality than index cards and sticky 
notes. Some customers and companies want documents that are a little more formal. 
It’s OK, though; everything you’ve learned still applies, and you don’t need to scrap a 
process that’s working just to dress up your development a bit. 


First, remember that unless you absolutely have to, wait until the end of your current 
iteration to make any changes to your process. Next, know why you’re making a 
change and how you’re going to measure its effectiveness. “The customer won’t pay 
me unless we have design documentation” is a perfectly reasonable starting point for 
dressing up your process. However, it’s still important to know how you’re going to 
measure effectiveness. Most customers are (rightfully) concerned about their business 
and aren’t just looking to give you extra work. 

If you’re going to put together more documentation, project plans, use cases, or 
anything else, make sure it helps your customer — and hopefully your team — be better 
at communication. That’s a result that is good for your project. 


Vo what you’re doing".just prettier 

Most of the work you’re doing can be captured and reported in a more formal 
fashion. With software and a little extra polish, everything from your big board to 
your user stories can be converted into something that meets your customer’s needs. 
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the real world 


Isn’t less formality better? Can’t I 
convince my customer that index cards 
are all I need? 

It’s not about more formal versus 
less formal. It’s about what works to get 
the right software written. The board with 
stories and tasks works well for lots of teams 
because it’s simple, visual, and effective 
at communicating what needs to be done. 

It’s not effective at lining up external teams 
that might be relying on your software or for 
when marketing should schedule the major 
release events and start shipping leaflets. 
Don’t add formality for the sake of being 
formal, but there are times when you will 
need more than index cards. 

If we have to use a project planning 
tool, should I keep the board too? 

Yes. There'll be some duplication of 
effort, but the board works so well with small 
teams that it’s very hard to get anything 
more effective. The tangible tasks hanging 
on the board that team members physically 
move around just keeps the team in sync 
better than a screenshot or printout does. 

My customer wants design 
documentation and just doesn’t get that 
my design just "evolves" … 



Dumb Quest? 


9ns 


Be careful with this one. Refactoring 
and evolutionary design work well with 
experienced teams who know their product, 
but it’s very easy to get something wrong. 

On top of that, not giving your customer 
the design documentation they want is 
asking them to take a huge leap of faith 
in what you’re doing—and that leap might 
not be justified yet. Most successful teams 
do at least some up-front design each 
iteration. You need to make sure the design 
documentation they're asking for is providing 
value, but design material is usually pretty 
useful for both you and the customer. Just 
make sure you account for the work in your 
estimates. Don’t let TDD or “evolutionary 
design” be an excuse for “random code that I 
typed in late last night.” 

My customer wants a requirements 
document, but user stories are working 
really well for my team. Now what? 

If your customer has a history with 
more formal requirements documents, it 
may be very difficult to make the shift to 
user stories. In general, you don’t want more 
than one requirement document directing 
how things should be implemented. It's very 
difficult to keep a document and user stories 
in sync, and someone always gets stuck 
resolving the conflicts. 


Instead, try starting with a user story and 
at the end of the iteration break up the user 
story into “the user shall” statements that 
can fit into a formal requirements document. 
Or, if the customer wants nothing to do with 
user stories, you can try going the other 
direction: pull several "The user shall” type 
statements into a user story and work from 
the stories. But watch out—those “the user 
shall” type requirements often don’t give you 
a lot of context about the application as a 
whole, and what it’s doing. 

Neither approach is ideal, but one may be 
a compromise that’s workable. You need to 
be absolutely diligent about changes in both 
directions, though. 

Ckoose a process 
tkat works lor 


YOUR team anct 
YOUR project... 


•“ and tken tailor 
tke artifacts 
it produces to 
matcli wkat 


YOUR customer 

wants anct needs. 
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other resources 


Some additional resources... 

Even with all of the new tools available to you, there’s always more to learn. Here 
are some places to go for some more great information on software development, 
and the techniques and approaches you’ve been learning about. 



h Bnlfi-FrtwdlJf (kd. 


Head First 



Head First PMP 

If you’ve managing your team, there’s more to good 
software — and project management — than just the big board. 

PMP takes you beyond the basics into a tried-and-true project 
management process — and help you get certified along the way. 

^ to^xdtYtd 

youVe leading ov- m dhav-gc o-f a 
iea% -this book Could help. 

丫 est - driven development Yahoo! group 

One of the all-time great resources for information on test- 
driven development is on the “Test-driven Development” group 
at Yahoo!. The group is pretty active, with current discussions 
and debates as well as some great historical information. You 
can find the group online at http : / / tech . groups . 
yahoo.com/group/testdrivendevelopment/. 



Head First Object-Oriented Analysis and Pesigh 

Want to get deeper into code? To learn more about object- 
oriented principles of design and implementation? If you loved 
drawing class diagrams and implementing the strategy pattern, 
check out this book for a lot more on getting down deep with 
code. 
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the real world 



Rational Unified Process web site 

One of the founding iterative processes is the Rational Unified 
Process (RUP). It’s a pretty heavy process out-of-the-box, but 
it’s designed to be tailored to your needs. It’s also a common 
approach to large-scale enterprise development. Be sure and read 
this and some Agile- or XP-leaning sites, so you get a balanced 
picture. Check it out online at http : // www-30 6 . ibm. com/ 
software/awdtools/rup/. 



The Agile Alliance 

The Agile Alliance is a great kickoff point for information on 
Agile processes like extreme programming, Scrum, or Crystal. 
Agile processes are very lightweight, and you’ll see many of the 
things you learned about, albeit from a different perspective at 
times. Check it out at http : / /www. agilealliance . org/. 


More knowledge -- better process 

There are tons more resources than just these. Part of good software 
development is keeping on top of what’s going on. And that means 
reading, Googling, asking your buddies on other projects — anything 
you can do to find out what other people are doing, and what works for 
them. 

And never be afraid to try something new, even for just an iteration. 
You never know what might work, or what you might pick up that’s just 
perfect for your project. 
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Tools for your Software Pevelopment Toolbox 

Software Development is all about developing 
and delivering great software. In this chapter, 
you got some additional resources to help you 
take your knowledge out into the real world. For 
a complete list of tools in the book, see 
Appendix ii. 
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...ar^di sor^C 
^osc tc6W°\^ s ’ 


Developrhehi P〆— pU 
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developer dah usually ovc^omc 


pvodcss. 
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七 cam be suddcss+ul. — ^ 


BULLET POINTS 

■ Take your team’s opinion 
into account whenever 
you’re going to make 
changes to the process; 
they have to live with your 
changes, too. 

■ Any process change should 
show up twice: once to 
decide to do it and once to 
evaluate whether or not it 
worked. 

■ Steer clear of more 
than one place to store 
requirements. It s always a 
maintenance nightmare. 

■ Be skeptical of magic, 
out-of-the-box processes. 

Each project has something 
unique to it, and your 
process should be flexible. 
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SoEfcwareDevelopmeiitcross 

This is it, the last crossword. This time the solutions 
are from anywhere in the book. 



Across 

3. Project planning tools can help with projections and 

presentation of schedule, but do them in parallel with 
your. 

4. No more than 15 minutes, these keep the team functioning 
as a team toward a common goal. 

7. Every iteration involves. 

8 . This is an approach where you write your tests first and 
refactor like mad. 

10. This is a process that checks out your code, builds it, and 
probably runs tests. 

11. High stakes game of estimation. 

13. Good Developers develop, Great developers. 

14. The team member you should estimate for. 

15. No matter what process you pick, develop. 

17. Every iteration involves. 


Down 

1. This means to evaluate processes critically and demand 
results from each of the practices they promote. 

2. Shows how you're progressing through an iteration. 

5. What you should be estimating in. 

6 . Every iteration involves. 

9. How you rack and stack your user stories. 

12. The greatest indicator of success or failure on a project. 

16. This is a process that tracks changes to your code and 
distributes them among developers. 
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exercise solutions 



Softwareltevelopitiettteross 
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Ifs time to leave a mark ow the ^0.world! 


the real world 



Were off to our new high paying 
job in software development! The 
worlds my oyster these days... 


There are exciting times ahead! Armed with ail of your software 
development knowledge, it’s time to put what you know to work...so get out there and 
change the world. Don’t forget that the realm of software never stops changing, either. 


Keep reading, learning, and please, if you can schedule it in your iteration, swing by 
Head First Labs (www.headfirstlabs.com) and drop us a note on how these tools have 
helped you out. ^ 
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Top Five Topics 

(we didn’t cover) 
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Ever feel like something’s missing? We know what you mean... 

Just when you thought you were done... there’s more. We couldn’t leave you without a few 
extra things, things we just couldn’t fit into the rest of the book. At least, not if you want to 
be able to carry this book around without a metallic case and castor wheels on the bottom. 
So take a peek and see what you (still) might be missing out on. 
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uml and class diagrams 


# 1. UML class diagrams 

When you were developing the iSwoon application in Chapters 4 and 5, we 
described the design using UML, the Unified Modeling Language, which is a 
language used to communicate just the important details about your code and 
application’s structure that other developers and customers need, without 
getting into things that aren’t necessary. 

UML is a great way of working through your design for iSwoon without getting too 
bogged down in code. After all, it’s pretty hard to look at 200 lines of code and focus 
on the big picture. 
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leftovers 


Class diagrams show relationships 

Glasses in your software don’t exist in a vacuum, they interact with each other 
at runtime and have relationships to each other. In this book you’ve seen two 
relationships, called association and inheritance. 


Association 

Association is where one class is made up of 
objects of another class. For example, you 
might say “A Date is associated with a collection 
of Events.” 



Inheritance 

Inheritance is useful when a class inherits 
from another class. For example, you 
might “A Sword inherits from Weapon.” 



Don’t I need a big expensive set of 
tools to create UML diagrams? 

No, not al all. The UML language was 
originally designed such that you could jot 
down a reasonably complex design with just 
a pencil and some paper. So if you've got 
access to a heavyweight UML modeling tool 
then that’s great, but you don’t actually need 
it to use UML 

So the class diagram isn’t a very 
complete representation of a class, is it? 

No, but it’s not meant to be. Class 
diagrams are just a way to communicate 
the basic details of a class’s variables and 
methods. It also makes it easy to talk about 
code without forcing you to wade through 
hundreds of lines of Java, or C, or Perl. 



I’ve got my own way of drawing 
classes; what’s wrong with that? 

There’s nothing wrong with your own 
notation, but it can make things harder for 
other people to understand. By using a 
standard like UML, we can all speak the 
same language and be sure we’re talking 
about the same thing in our diagrams 

So who came up with this UML deal, 
anyway? 

The UML specification was developed 
by Rational Software, under the leadership 
of Grady Booch, Ivar Jacobson, and Jim 
Rumbaugh (three really smart guys). These 
days it’s managed by the OMG, the Object 
Management Group. 


Q/ Sounds like a lot of fuss over that 
simple little class diagram thing. 

UML is actually a lot more than that 
class diagram. UML has diagrams for the 
state of your objects, the sequence of events 
in your application, and it even has a way 
to represent customer requirements and 
interactions with your system. And there's a 
lot more to learn about class diagrams, too. 
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sequence diagrams 


Sequence diagrams 


A static class diagram only goes so far. It shows you the classes that make up 
your software, but it doesn’t show how those classes work together. For that, 
you need a UML sequence diagram. A sequence diagram is just what it 
sounds like: a visual way to show the order of events that happen, such as 
invoking methods on classes, between the different parts of your software. 
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user stories and use cases 


User stories and use cases 

You used user stories throughout this book to capture your requirements. 
User stories are really great at getting a neat description of exactly what 
the customer needs your software to do. But a lot of more formal processes 
recommend something called a use case. 

Luckily, there’s easily enough overlap between user stories and use cases for 
you to use either technique to capture your customer’s requirements: 


從卜 a 


Title 


Scwdapicturci： 0 
other users 


Estimate: 


A user story 
anct a use 


case 


beeh pvepaved -fov- youv 
p\rojc^-t bodird 匕。 irtaihs a 

pvioHty avxd ah estimate 


describe ONE 

iTOGtwr 

your software 
needs to ao. 
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A 的 c^uivalc^t Use Case 

七 ha 七 describes *bV^c sa^c 
w Scr\d a pit*bu\rc *to otiicv- 

uscv-s w 


^bscirva-tioh 
•s 3 key 
^or^pohCh-t 
,h JettihJ 
good use cases 
^V-iHeh. 


/\ use case’s sc<\uc^c 
normally dor\*ta'ms rno\TC 

steps a^d dc*b3il a 
usev s*tov-y. TiVis makes 
i 七 casicv *to y/ovk *to 
-fov- dcvclopcv-s, bu*b 
medyts c%*bva >wovk 
七 he fi.us*tomCV" bo r\3il 
七 hese details do 職 . 


Send a picture to other users 

1. Click on the "Send a Picture button' 

么 display users the picture caw be sewt to m 

the address book list box. 

searchbor 6 desf 州 0M wer s "職 in the 

2b - C,ick om search to find the user 

炙 Select the user to send the picture to 

4. Click on send 

5 2 滅 ㈣ 物 wam 讀 epf 

5a.l. The receiver accepts the photo 
办.么 The receiver views the photo 
5b.l. The reoevier rejects the photo 
5b.2. The photo is trashed. 


y 财 ^usio^ 


*yt dv^e d r\umbcv- <Jc 
v/ays i\\^i you 

|*tc do 如於 a use ^3sc* TVis 
des^ibes *tV^ 'm*tcv-a^tior\s 
a usev- Kas >/i*bK *tV>c 
: *Uave, step by step. 


So what’s the big difference? 

Well, actually not a lot, really. User stories are usually around three lines long, and are 
accompanied by an estimate and a priority, so the information is all in one bite-sized place. 
Use cases are usually reasonably more detailed descriptions of a user’s interaction with the 
software. Use cases also aren’t usually written along with a priority or an estimate — those 
details are often captured elsewhere, in more detailed design documentation. 


User stories are ideally written by the customer, whereas traditionally use cases are not. 
Ultimately either approach does the same job, capturing what your customer needs your 
software to do. And one use case, with alternate paths (different ways to use the software in 
a specific situation) may capture more than one user story. 
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system testing vs. unit testing 


# 4. System tests vs. mi tests 


In chapters 7 and 8, you learned how to build testing and continuous integration 
into your development process. Testing is one of the key tools you have to prove that 

your code works and meets the requirements set by your customer. These two 
different goals are supported by two different types of tests. 

Unit tests test your CODE 

Unit tests are used to test that your code does what it should. These are the 
tests that you build right into your continuous build and integration cycle, to 
make sure that any changes that you make to code don’t break these tests, on 
your code and the rest of the code base. 

Ideally, every class in your software should have an associated unit test. In fact, 
with test-driven development, your tests are developed before any code is even 
written, so there is no code without a test. Unit tests have their limits, though. 
For example, maybe you make sure that calling drive () on the Automobile 
class works... but what happens when other instances of Automobile are also 
driving, and using the same RaceTrack object, too? 



Whit testmg is at a vcv-y 
low level... souv-dc -files 
dcs^vip-fcovs. 


System tests test your SOFTWARE 

System tests pick up where unit tests leave off. A system test tests your 
code when it is integrated into a fully functional system. System 
tests are sometimes automated, but often involve someone actually 
exercising your entire system in very much the same way as the end 
user will. 

For example, you might fire up the GUI for monitoring a race, press the 
“Start Race” button, watch animated versions of cars spin around the track, 
and then initiate a wreck. Does everything work the way the customer 
expects? That ? s a system test. 



El 

1 _ 

ZJ 


tWeiqre no ^ 

—— Dumb Questions —— 

In addition to unit and system tests, aren’t 
there lots of other types of tests as well? 

Yes. Testing is a BIG field of work. There are 
various names for testing, conducted at anything from 
the source code level to enterprise software integration 
level. For example, you may hear of acceptance tests. 
Acceptance tests are often conducted with the customer, 
where the customer either accepts or rejects your 
software as doing what they need.. 




Unit tests prove that 

your code WORKS* 

System tests prove tkat 
your software meets its 
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巧 . Rcfactorlwg 


Refactoring is the process of modifying the structure of your code, 
without modifying its behavior. Refactoring is done to increase the 
cleanness, flexibility, and extensibility of your code, and usually is 
related to a specific improvement in your design. 


Most refactorings are fairly simple, and focus on one specific design 
aspect of your code. For example: 


public double getDisabilityAmount() { 

// Check for eligibility 
if (seniority < 2) 
return 0; 

if (monthsDisabled > 12) 
return 0; 
if (isPartTime) 
return 0; 

// Calculate disability amount and return it 

} 

While there’s nothing particularly wrong with this code, it’s not as 
maintainable as it could be. The getDisabilityAmount () 
method is really doing two things: checking the eligibility for disability, 
and then calculating the amount. 

By now, you should know that violates the Single Responsibility 
Principle. We really should separate the code that handles eligibility 
requirements from the code that does disability calculations. So we can 


Relactoring 
cltanges tlie 
internal structure 
ol your code 

WITHOUT 

aWecting your 
code’s tekavion 


refactor this code to look more like this: 

public double getDisabilityAmount() 
// Check for eligibility 

if (isEligibleForDisability()) { 



^ vc -takch -two ircspohsibilitics, 

them ih two scyaraic 
methods, adhcHhg -fco the S/^p. 


// Calculate disability amount and return it 


} else { 
return 0; 


Now, if the eligibility requirements for disability change, only the 

isEligibleForDisability () methods needs to change — and 
the method responsible for calculating the disability amount doesn’t. 

Think of refactoring as a checkup for your code. It should be an 
ongoing process, as code that is left alone tends to become harder and 
harder to reuse. Go back to old code, and refactor it to take advantage 
of new design techniques you’ve learned. The programmers who have 
to maintain and reuse your code will thank you for it. 
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#- 


Tools for the Experienced 

♦Software Developer 


pcvcloywevA 


cs 


|Wat»ov> V>cl\>s you 
Pbv> ou*b 

▲ 灼 （灼。七 J) 如 ％| 


^ adabie 一 uhd ^^bi c code 


d.US-bow'CV' CVCV'Y s *t c ? 


Dcvclop^cht pHhdipIcs 

h hohes-t wi-th youv dus-tomcv, csp^ially 
wheh the hews is bad. 

I/Voirkihg so^twavc is youir -fcop pviovity. 


乙 lose SCCOY\d. 


tomes ^ 


W you havch't tested a pic^ 乙 0( ^ 

assurhe 七 i*t docsh ； t woV'k. 

Fix -Puhd*tiohali"ty. 

Be p\roud youv Code 

All -the Code ih you\r so^iv/^e, cvc h the 
bits you didh ； t wiritc, is youv^ wpohsibility. 


Ever wished all those great tools and techniques were 
in one place? This is a roundup of all the software development 
techniques and principles we’ve covered. Take a look over them all, and 
see if you can remember what each one means. You might even want to 
cut these pages out and tape them to the bottom of your big board, for 
everyone to see in your daily standup meetings. 
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Developitigpt T echn igues 





Itcvatioh helps you stay Oh douv-sc 

Plan out ar\d bala^de youv i-tevatiohs v/hch 
(ir\ 0 *t i-f) odduV"S 



tvevy i*tcv-a*tio^ \rcsul-b *m y/ov-km^ so^tv/dv-c 
a 灼 d jathevs -feedback -fvom youv dus-fcomev- 
cvcvy step o^* the way 


【癱 • 


Blucsky, Obsev-vatioh, a^d Rolcplay -to -Piguv-c 
ou*t hov/ youv- system should behave 

Use usc\r s*to\rics *to keep the -fodus oh 

-fuhd*tiohali*ty 

Play plahhihj poker -for estima 七 ioh 


I'tcV'd'tioirvS should idcdlly be v\0 loh^CV* "tha 灼 
a ^ovsiW Thai ^ca^s you have ZO v/ovkm^ 
^ale^dav* days pev i-tevaiio^ 

vclod.i*ty *to youv lc*ts you -Peel 

move do^idch-t *m youv abiliiy *to keep youv 

dcvdopmChi pvo^iscs *to youv tus-tomcv* 

Use Oi*tcvally) a bi^ boavd ov\ youv v/all *to 

pldh dhd r^oir»*rto\r youv £.uv*\rcir\*b 灼 s 

y/ovk 

^C*t youv ^us-tomcv^s buy-*m v/hcirv dhoosm^ 
v/ha*t user s*tovics £.3 kv be Completed -fov 
Milestone l -O, Sv\d yj\)Cv\ dV>oos*m^ Y/ha*t 
i*tcv*a*tioh a user s*to\ry v/ill be built m 


v/ou d,‘UWmk 如 c^scs ovc^, 
a\a you? V\M*bc Y 雜卿 iceM^ts \or 
CV^fbevs 今 ay\d 一 ^ 


to 



Use d vc\rsioh doirbrol *tool *bo *t\r3dk 
distribute dhah^es'm you\r so-f*tv/a\rc *to youv 
七 0 

IXsc *t3gs *fco keep *t\r3dk o-f major milcs-bohCS 
ih you\r p\rojcd*t Cchds o-f i*tc\ra*tiohS, VC I eases, 
bu^ -Piy.es, c*td.) 

Use bra^dhes -fco maih-bdih a separate dopy 

o-f you\r dode ； but ohly i-f absolutely 

hcdcssavy 
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Wse a build -tool -to script buildih ^； padkag.m% 
ahd dcployihj your system 

/Wosi IDEs are already usih^ a build -bool 

Uhdc\rhcath. 6\ci familiar Y/iih that tool, 
ahd you cby\ build oh v/ha*t the IVB already 
docs 

Treat you\r build sd\ript like todt ahd c\\tck 
i*t ih*fco vc\rsioh doh*brol 


【癱 i 


There avc di 以 ereyrt viev/s <Jc you\r sys-tfm, 
av\d you r\ttA bo -tes-t all 

Testm^ has *to addou^-t -fov* suddess ddses 5s 
v/ell ds -failure £-3scs 

Au*tor«a*tc y/hc^cvcv- possible 

Use d dorvtmuous *m-tc^\ra*tioh *tool "to 
au-tomatc build'm^ arvd you\r Code oy\ 

l/V\ri*te -tesis -fi\rs*t, {\\CY\ Code *to make -those 
■tesis pass 

Your -tests should -fail *mi*tiallyj a-f*tcr 
they pass you dah \rc-fad-to\r 

Use modk objcd*ts *to provide va\ria*tioy\s oy\ 
objcd*ts *th3*t you heed -for 

P<9y 3*t*tch*tioh *to you\r bu\rh—dowh y*3*tc- 
cspcdially a-f-tcr the i-tcratioh ehds 

(■tcV"3*tioh is inr\po\rt3h*t 一 d\rop s*tov*ics i*( 

you heed *to keep it gomg 

Doh 七 fuhisli people -fo\r yttmg dohe early— 
i*f 七 heiv stu-P-f works, Ie 七 them use 七 he c>c*tva 

"to o\r Ic3\rh somethihj hew 


Wha 七 did you lea\rh ih Cliaptcv -1 Of 
it dovm hcv-c. 


Before you d l*mc dodc, 

make suve i*t is doy\*tv*ollcd buildablc 

W\\tY\ buy hi*t toAt you do^-t khow, use a 
spike -test *to cstn^a*tc hov/ lo^ i*t will take 

*bo -fix. 

Factor *m youv- -tcarw^s CoY\^\dtY\tC 
cs-timatrn^ -the v/o\rk -to -f ix. bu^s 

Use *tcsts "to -tell you >u\\CY\ d bu^ is -fi^cd 


Cv"i*ti 乙 ally evaluate 3hy *to you\ 

fv-odess y/i-th real mcirids 

dliz-c your deliverables i-f you ^eed 

I ill * 

to, bu 七 always khov/ how i*t’s providih^ 

value 

Try hard *to only your prodess 

beiv/cch i*tcra*tiohs 
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Developigenf; Principles 



The dustonr»c\r khows what they but 

so^ch^ts you heed to help i\\c^ hdil \i dovm 

Keep \rc^uiv*Cnr»Ch*b dus-tor^cv-ovichtcd 

Develop 3 hd V-C-PihC youv* V*C^uiv*Cry»Ch*b 
itcvativcly with dustor^cv* 


Keep i"bcv* 3 *bio^s shov*b a 於 d ma^a^cablc 

Ul-bi^a-bcly, *b^c ^ustomcv decides Ua*b is m 

a 灼 d >wha*b is ou*b -fov Milcs-to^c \ 0 I 

PvWise, at\A dclWcv 
ALIA/A Vs be honest y/rbli the dusWcv* 



!Wl 



s based … 七， 

leaded m 七吖弓 . 

/\|v/ays k^ov/ y/hcv-c should (^t\d 

shouldn't) 5° 

^ov/ y/ha-b code v / ⑼七 \y\{jo a _ ⑼ v-clcasc— 
a^d be able *to yb *to *rb 33 dm 

Co^-tv-ol toAt 乩 a^d distvibu-bio^ 


Buildihg a pv-ojedt should be repeatable a^d 
au-fcoma-ted 

Build Sdv-ipts set the s-tage -fov- othev- 
au*toma*tioh -tools 

Build sd\rip*ts jo beyohd just s-tep—by—s*tcp 
au-tow\a*tioh 3hd dah daptuv-c dompilaiioh 3hd 
dcploymcht lo^id dedisiohs 


l/Ve didh ； t add a^y tc^hhi^ucs a^d 

p\rih^iplcs -to Ch 外七饮午 … you 
tome up with a -Pew dhd wv-itc 
therw hc\rc? 
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is a -tool -to lei you k 灼 ov/ v/hev-c you\T 

pvojcd-t is a*t all *ti^cs 

Co^tmuous ih-tc^vatio^ ^ives you doh-fidchde 
•that i\\t todt *m youv veposi-tovy is dovveti 
ar\d builds pvopcvly 

Code doveva^e is a 州 udh bc-ticv* mc-tvid of 
icstmj c-f-fctiivchcss ihah tesi douirrt 



"TDD -Po\rdcs you "to -Podus oh -Puhdtiohali-ty 

Au-tomated tests wake rc-fad-torihg sa-Per; 
youll khow immediately i-P you^vc broken 
sor^c-thihj 

与 ood toAt dovc\r3jc is mudh ry»o\rc 3dhicv3blc 

•m a TDD approach 


|-bcvd*bio^s avc a >way *to impose *m*bcv*mcdia*bc 
dcddlmcs—s-bi^k *to *b^c^ 

Al 哪 estimate 4v the ideal day ^ov -the 

aveva^e membev* 

Jsccf *b^c fi6*buve m mmd vjhem 

i*bcva*bio^s—ar\d *b^a*b —Vvb mdude e’tev^al 

•bestm^ of *blic sysiemn 
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Chaptev 10 v/as all about *tK'i\rd-party 
Code- fv'md'iplcs did you fitk up? 


Be honest v/i*th youv- dus-fcomcv, cspcdially 
y/hch -the hCv/s is bad 

l/Vbrkm^ so^tv/av-c is youv* *fcop pvio\r*rty 

Readable and u^dcvsta^dablc CoAt domes a 
dlose sc^o^d 

l-f you havch *t tested a piede dodc, 
assume that rt docs^-t v/ov-k 

Fi% -fu^*tioy\ali-ty 

Be p\roud cvf youv* CoAt 

All the dode m youv so^twave, -the bits 
you didh *t v/v-i-tc, is youv v-cspo^sibili-ty 


与 ood developers develop—gvcai 
developers ship 

与 ood developers cat\ usually overcome d 
bdd process 
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i,C 3 n\ be suddess-Pul 
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batch files 227 

talking to customer about 386 
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building projects (continued) 

generating documentation 228 
good build scripts 228, 230—231 
tools 224, 227 
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bugs 200 

building projects 234 
build tool 233 

continuous integration (Cl) 274 

controlled and buildable code 414 

fixing bugs 395 

iteration 26 

process changes 428 

project planning 103,106 

system testing 346 

test-driven development 314 

testing 274 

third-party code 380 

user stories 66 

velocity 380 

version control 207, 216 

Burn Down chart 115 

Burn Down graph 102,104 
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CM (configuration management) 188 
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clean target 229 
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code 

branching (see branching code) 
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convergence 57, 58 
coverage report 408 
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customers 
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blue skying requirements 34 

bug fix estimate 406 

changing features 20—23 
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managing unhappy 98 

not being able to meet deadline 75, 97 
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dashboard 100—101 
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not being able to meet 75, 97 
delivering software (see releasing software) 
delivering what’s needed 73 

demo 167 

failure 185, 187 
dependencies 293-295, 391 
spike testing 408 
dependency injection 308,310 

design 149—176 
cohesion 161 

DRY (see don’t repeat yourself) 
evolutionary 425 
flexible 165 

perfect versus good enough 168—169, 409 
productive 165 

spotting classes not using SRP 156 

SRP (see single responsibility principle (SRP)) 

design documentation 425 

developer testing 325 

development time 76 

documentation, testing 243 

documenting code 391 
spike testing 408 
don’t repeat yourself (DRY) 160 
versus SRP 161 
DRY (see don’t repeat yourself) 

E 

equals method, Java 308 
error handling, proper 243 

estimates 43, 99 
assumptions 47 

eliminating 48—49, 51 
better-than-best-case 90 


bug fixing tasks 409 
bugs 358 

convergence of user story estimates 57, 58 

different results 358 

iteration 60—61 

large gaps 50 

reprioritizing 75 

real-world days 91 

recalculating estimates and velocity at each iteration 
353 

task (see tasks, estimates) 

user story estimates greater than 15 days 54 

when too long 92 

whole project (see project estimates) 

evaluation 418 
evolutionary design 425 

F 

features 

customers changing 20—23 
dependent on other features 19 
prioritizing new 22 
(see also priority setting, requirements) 

Fireside Ghats 

iteration and milestone 82-83 

perfect design versus good-enough design 168-169 

flexible design 165 

functionality 395 
baseline 75, 79 

figuring out what functionality works 396, 399 
testing 239 

G 

good-enough design 168-169 
grey box 238 
grey-box testing 240 
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Head First Java BeatBox project 178—183 
demo failure 185 
GUI 182 

networking code 184 
testing 183 

honesty 75, 96, 98, 103, 106 



inheritance 435 
input and output 239 
interdependencies 295 

interfaces, multiple implementations of a single interface 
296 

iteration 10-15, 19, 84 

adding more people to project 19 

adding time to end of 323 

bad 345 

balanced 85 

changing features 22—23 

communication and 329—330 

estimates 60—61 

Fireside Ghats 82-83 

fixed iteration length 328 

handling each as mini-project 14—15 

length of iteration and spike testing 409 

monitoring 100—102 ， 104, 106 

necessity of 12 

not enough time for story 345 

pacing 346 

prototyping solutions 344 
pulling stories for next 344 
reviewing 342—343 

elements of review 342 
review questions 343 
reworking plans 23 
short 85 
short projects 12 

software development process 418 


system testing 327-329 

fixing bugs while continuing working 329 
time at end 345 
versus process 24 

when everything is complete 170—171 

when new requirements come in during last 25 

when new requirements won’t fit current 25 

when to begin 12 

when too long 92 

(see also iteration, next) 

iteration, next 352-382 
bugs 358 

customer approval 360 
planning for 352 

recalculating estimates and velocity 353 
velocity 359 



Java’s equals method 308 
Java programming 181 
Java projects 227 

JUnit 247, 250-251 

adding to Ant build 254 
invoking test runner 251 



learning time 344 
logging 240 

loosely coupled code 300, 303 

M 

Mantis 336 
maximum team size 77 

Mercury Meals project 360—382 
building project 392 
estimates 362 

figuring out what functionality works 396, 399 
fixing functionality 394—395 


452 Index 



the index 


integrating code 369 
priorities 362 

third-party code, testing 370 
user stories 362 

metrics 419 

milestones 73, 74, 99 
Fireside Ghats 82-83 
versus versions 75 
(see also priority setting) 

mock object framework 304—308 


evolutionary design 425 

features, dependent on other features 19 

formal process 425 

getting code into a “pretty decent” state 409 
good-enough code 164 
having each class do only one thing 161 
integrating the Mercury Meals code 369 
iteration 84 

adding more people to project 19 
adding time to end of 323 
bad 345 


multiple implementations of a single interface 296 

multiple responsibilities 156 

going from multiple to single 159 


necessity of 12 

not enough time for story 345 

short projects 12 

time at end 345 


K 

nice-to-haves 73 

No Dumb Questions 
assumptions 53, 58 
baseline functionality 75 
batch file or shell script 227 
BeatBox 181 

bin, dist, and src directory names 227 

branched code 210 

bugs 

fixing 409 
priority setting 358 
building projects 
build script 227 
default target 227 
tools 227 

burn-down rate 323 
lowering 118 
cohesion 161 

committing changes to a tag 210 
continuous integration (Cl) 253 
convergence of estimates 58 
customers, how much of process should 
customers see 58 
design documentation 425 
estimates 99 

bug fixing tasks 409 
bugs 358 

different results 358 


time constraints 19 

when new requirements come in during last 25 
when new requirements won’t fit current 25 
when to begin 12 
Java programming 181 
milestones 99 

milestones versus versions 75 

mock objects 308 

networking code 184 

not being able to meet deadlines 75 

perfect versus good enough design 409 

planning poker 53 

POKE—START—SEQUENCE 181 

priority setting 78, 80 

project planning tool 425 

repository location 210 

requirements 

before requirements are set 32 
refining 40 
versus iteration 12 
requirements document 425 
Runnable 181 


software development techniques 181 
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copy command 210 
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task estimates 114 
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allocating 118 
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technical terms 40 
test driven development 287 
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dependency injection 308 
making assumptions 292 
mock objects 308 
strings that aren’t constants 292 
writing code you know is wrong 298 
testing 

coverage tools 266 
developers 325 
getting started 266 
how often 249 
setters and getters 287 
tests 440 
third-party code 

compiled code 369 
non-working 369 
problems with 380 
reusing code 365 
user stories 365 
threading 181 
UML diagrams 435 
underestimating time 323 
user stories 40, 53 

better understanding 58 

bug fixing represented as user story 358 
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slower 358 
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version control 
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log command 210 
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object stand ins 303-308 
observation 37 
off-by-one errors 239 
office politics 34 
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output results 239 
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packaging compiled version 391 
spike testing 408 
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general priority list for getting extra things done 344 
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third-party code 379 
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bugs 200 
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project board 100—101 ， 106 ， 116— 117， 164 
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unexpected tasks 166 
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project estimates 63 
too long 64 

project planning 69-108 
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customer’s priorities (see priority setting) 

delivering what’s needed 73 
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reprioritizing 75, 78 
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prototyping solutions 344 
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quantitative data 403 

R 

Rational Unified Process (RUP) 427 
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customer’s perspective 39 
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25 
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requirements document 425 
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reusing code 365 

reverse-engineering code 391,408 

risks 51 
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SRP analysis 159 
versus DRY 161 


you are here ► 


455 


the index 


singularly focused 152 

software 

testing 440 
working 350—351 

software development dashboard 100-101 
software development process 418-419 
source code, more than one version 200 
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coverage report 408 
dependencies 408 
documenting code 408 
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state transitions 239 
strategy pattern 296, 303, 310 
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commit changes 197 
copy command 210 
trunk directory 197 

successful development 418—419 
system documentation 333 


system testing 324-337 
bugs 

reports 337 
tracking 336 
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documenting tests 333 
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fixing bugs while continuing working 329 

iteration cycles 327 

life cycle of bugs 334—335 

never test your own code 325 

priority setting 338, 341 
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versus unit testing 440 
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advantages of testing 300 
automated testing 302 
cycle 281 

dependencies 293-295 

dependency injection 308, 310 

focusing on small bits of code 281 

getting your tests to green 280 

initial failure 279 

interdependencies 295 

keeping test code with tests 299 

keeping tests manageable and effective 286 

loosely coupled code 300, 303 

making assumptions 292 

mock object framework 304—308 

more tests means more code 302 

multiple implementations of a single interface 296 

object stand ins 303-308 

process overview 312—313 

replay() method 308 

Rule #1: Your test should always FAIL before you 
implement any code. 279 
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SIBLE to make your tests pass. 280, 294, 301 
strategy pattern 296, 303, 310 
strings that aren’t constants 292 
tasks 

analyzing 277 
completing 288 
moving to next one 289 
testing bad habits 309 
things to remember 310 
tightly coupled code 295, 300 
writing testable code 294 
writing tests for failing 290 
writing tests for passing 290 

tester testing 325 

testing 183, 236-274 
advantages 300 

automated 248, 250-251, 302, 333 
bad habits 309 
black-box 239 
boundary cases 239 
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reports 337 
tracking 336 

code coverage 259, 263—267 
reports 265 

continuous integration (Cl) 252-253, 270 
scheduling build 255 
tool 254-256 

data destined for other systems 240 
developer 325 

different branches of code 243 

documentation 243 

documenting tests 333 

error handling 243 

figuring out what to test 247 
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functionality 239 

getting started 266 

grey-box 240 

how often 249 

life cycle of bugs 334—335 

more tests means more code 302 

off-by-one errors 239 

output results 239 

regression 248 

resource constraints 243 

scheduling build 255 

scraps left laying around 240 

setters and getters 287 

spike (see spike testing) 
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suite of tests 248 

system (see system testing) 
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tester 325 

third-party code 370 
three ways to look at system 238 
unit (see unit testing) 
user input validation 239 
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compiled code 369 
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non-working 369 
problems with 380 
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reusing code 365 
testing 370 
trust no one 373 
user stories 365 

threading 181 

tightly coupled code 295, 300 
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development principles 428 
automated tests 314 
build scripts 234 
code coverage 274 
continuous integration (GI) 274 
customer buy-in 106 
delivering software 26 
delivery of what’s promised 106 
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helping customers nail down requirements 66 
honesty 106, 414 
iterations 106, 346 
planning iterations 346 
readable and understandable code 414 
requirements 66 
test-driven development 314 
testing 274 
version control 216 
working software 414 
development techniques 
big board on wall 106 
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branches 216 
build script 234 
build tool 234 
burn-down rate 346 
changing process 428 
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mock objects 314 
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spike testing 414 

tags 216 
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testing 274 
user stories 66 
velocity 106 
version control 216 
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unit testing 278, 324 
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slower 358 
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versus overworking staff 103 

version control 188—218 
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checking out and committing works 197 
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non-conflicting code and methods 193 
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what version control does 214 
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what and when of projects 43 
white box 238 
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